Re: aide 0.8-2 moved /etc/aide/aide.conf to /usr/local/etc/aide.conf

[Adam Majer]

[EMAIL PROTECTED] wrote:

>Hello,
>
>I've just installed aide for woody but it was required to
>move /etc/aide/aide.conf to /usr/local/etc/aide.conf.
>
>Can someone reproduce this if it's a bug or not ?
>
>  
>
# apt-cache policy aide
aide:
  Installed: 0.8-2
  Candidate: 0.8-2
  Version Table:
 *** 0.8-2 0

No problems here. Aide conf file is in /etc/aide as it is suppose to be.

- Adam

-- 
Building your applications one byte at a time
http://www.galacticasoftware.com

AMD64 Archive Key compromised!

[Adam Majer]

Matthew Garrett wrote:

>Developers, do not allow 
>
>http://www.google.com/search?q=inurl%3Asecring.gpg
>
>to happen to you.
>
>  
>
Yeah.

debian-amd64.alioth.debian.org/pure64/wanna-build/secring.gpg

is Forbidden, but

ftp.belnet.be/linux/debian-amd64/wanna-build/secring.gpg

ftp.belnet.be/pub/mirror/debian-amd64.alioth.debian.org/wanna-build/secring.gpg


are wide open.

So, with no further delay, here's the revocation certificate for the
AMD64 archive key!
Man, people had secret keys on broken in machines and those were removed
from the archive. But to have a secring.gpg on Google?

I also took the liberty to send this revocation certificate to
keyring.debian.org

-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: A revocation certificate should follow

iGYEIBECACYFAkGBKG4fHQJzZWNyaW5nLmdwZyBmb3VuZCBvbiBHb29nbGUhIQAK
CRCVXxufOIK6/GbFAJ4yTldjZzm015upfsAcKwNoFf5y8wCdHRGITdO2XRWnbZy+
3q7JMAf9CI4=
=rMmn
-END PGP PUBLIC KEY BLOCK-

-- 
Building your applications one byte at a time
http://www.galacticasoftware.com

Re: Apt-Torrent project

[Adam Majer]

Henrique de Moraes Holschuh wrote:

>On Sun, 31 Oct 2004, Steinar H. Gunderson wrote:
>  
>
>
>The Azureus Java client does this, so yes, it is possible.  How bad this
>interacts with the scatter-gatter logic of BT, I don't know.  But the
>.torrent files would be huge, and they would need to be updated daily,
>which would break all torrents.  So, it is useless for unstable.
>  
>
Most ISPs probably have caches for at least HTTP traffic. I would expect
that these would cache most of the debs, that is, if enough people are
downloading these packages.

BT doesn't make too much sense here. It is only useful for large files
that do not change often, like woody iso images.

- Adam

-- 
Building your applications one byte at a time
http://www.galacticasoftware.com

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Adam Majer]

Will Newton wrote:

>On Thursday 02 Dec 2004 09:27, David Weinehall wrote:
>  
>
>>>So far so sarcastic. IMO if it can be demonstrated that distributing
>>>something is illegal we should think about not distributing it.
>>>  
>>>
>>And, as demonstrated elsewhere in the thread, whoops goes
>>bible-kjv-text.
>>
>>
>I know of no country where that is illegal. If someone can name one with 
>evidence then we may consider it.
>  
>
China would *appear* to be one,

http://archives.cnn.com/2002/WORLD/asiapcf/east/01/28/china.bibles/
http://www.upi.com/view.cfm?StoryID=28012002-054849-9679r

>I don't see how that package is integral to Debian anyway.
>  
>
A significant number of packages in Debian are not integral to Debian.



-- 
The email address used to send this email is temporary.
It is bound to disappear at any time. Please thank the
morons that buy crap from spammers for this.

Bug#293055: ITP: rails -- MCV ruby based framework geared for web application development

[Adam Majer]

Package: wnpp
Severity: wishlist
Owner: Adam Majer <[EMAIL PROTECTED]>

* Package name: rails
  Version : 0.9.5
  Upstream Author : David Heinemeier Hansson 
* URL : http://www.rubyonrails.com
* License : MIT
  Description : MVC ruby based framework geared for web application 
development

Rails is a full-stack, open-source web framework in Ruby for writing
real-world applications.

Being a full-stack framework means that all layers are built to work
seamlessly together. That way you don't repeat yourself and you can
use a single language from top to bottom. Everything from templates to
control flow to business logic is written in Ruby.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: Bug#293055: ITP: rails -- MCV ruby based framework geared for web application development

[Adam Majer]

David Nusinow wrote:

>I worked on a package for this throughout the weekend, and while it's not done
>I've made some considerable progress on it. If you'd like help or a
>comaintainer, let me know.
>  
>

For the package, I essentially want to take rails and stuff it (minus
the non-software stuff in upstream tarball) in /usr/share/rails/ with a
deployment script in /usr/bin. Then you'll be able to type `rails
my_app` and empty rails framework would deploy to `pwd`/my_app.

The /usr/bin/rails script will also have a -P,--production switch that
will deploy the framework for production environment (ie. no docs or
unneeded parts of the framework).

I will be using rails next week so the package will be ready by end of
the weekend.

What does your package look like? Do you have a place where I can
download it?

- Adam



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

Re: Orphaning three packages

[Adam Majer]

Neil McGovern wrote:

>Hi all,
>
>I'm orphaning three packages:
>hawhaw-doc - the documentation for HAWHAW and HAWXY
>hawxy - a script that makes PHP-enabled webservers to HAWHAW proxies
>libphp-hawhaw - a PHP toolkit to create universal mobile applications
>
>RFAs have been filed for all of them.
>
>If no one wants them, I'll ask for their removal.
>
>  
>

That should be O: not RFA:, especially since you will not maintain these
yourself.

- Adam


-- 
The email address used to send this email is temporary.
It is bound to disappear at any time. Please thank the
morons that buy crap from spammers for this.




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

Re: Add a videocard to Discover

[Adam Majer]

Paul van der Vlis wrote:

> Hello,
>
> During install my videocard is not detected by Debconf. It is a cheap
> Nvidia compatible videocard what uses the "nv" driver.
>
> How can I tell the Discover-developpers about this videocard?
>

`reportbug discover` will do the trick.

Just forward the report there. lspci -v is sufficient, but what you have
is good too.

The PCI ID of the card is: 10de:0185 (from /usr/share/misc/pci.ids). You
can get that id directly if you run

`lspci -s 1:0 -n`

The -n option prevents lspci from translating the PCI id to the string
version.

- Adam


-- 
The email address used to send this email is temporary.
It is bound to disappear at any time. Please thank the
morons that buy crap from spammers for this.



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

Re: the ongoing xfree86 buildd saga

[Adam Majer]

Wouter Verhelst wrote:

>On Wed, Feb 23, 2005 at 12:41:46PM -0800, Thomas Bushnell BSG wrote:
>  
>
>>What I'm saying is that once it's cleaned up, I have two options:
>>
>>* ask for my package to be requeued;
>>* do another upload.
>>
>>And I'm almost certain that the latter option is faster, and that the
>>former option will have an unpredictable delay of up to a week.
>>
>>
>
>What I'm saying is that the delay is likely in cleaning up, not
>necessarily in requeueing. Hence, your upload will likely break again,
>in exactly the same way it did before.
>  
>

Not necessarily. When I attempted to get mysql-query-browser requeued on
arm two weeks ago, I sent an email to the arm porting list and James
Troup as he is listed the buildd maintainer on
http://www.debian.org/ports/arm/. No response. No comment. Nothing. So
it was faster just to reupload a week later.

- Adam



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

Re: Tips wanted for debugging and testing Debian

[Adam Majer]

Sascha Berkenkamp wrote:

>I use Debian unstable on my laptop, testing on my old PIII which runs
>some server taks for my local net and a Debian stable on a Webserver. 
>I prefer to work on my old PIII, but I don't want to destroy my running
>Debian. Should I install Debian on a second partition or is there any
>possibility to run one Debian (or twice... ) for debugging in a virtual
>server, like bochs?
>  
>

Read,

http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot

You don't even need a second partition :)

- Adam



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

Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)

[Adam Majer]

Andreas Barth wrote:

> Actually, I believe the Debian project as whole _wants_ to getting
>
>software released. That was at least the decision in all GRs where
>people didn't hide the intents ("editorial changes").
>  
>

Indeed. These types of changes are akin to changing a country's
constitution and calling these "editorial changes" bill. But then again
we can always change it back and call the change "editorial changes" as
well.

- Adam



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

Ubuntu and its "appropriation" of Debian maintainers

[Adam Majer]

Hi,

I just search Google for me and I found this,

https://launchpad.ubuntu.com/people/adamm/

Now, I never signed up to be a maintainer for Ubuntu. I don't understand
why I am part of "people of Ubuntu" or why I am listed as a maintainer
of any package on Ubuntu's website? I know Ubuntu is using my packages
as part of their distribution. I have no problem with that. What I do
have a problem is the use of my name and my resources (time) in
association with Ubuntu *without* my permission.


Well, at least on pages like,

http://packages.ubuntu.com/hoary/misc/mysql-query-browser

They have "Adam Majer is responsible for this Debian package" with a
link to Debian's QA. This reference I find acceptable, but better
wording would be "Adam Majer is responsible for the Debian version of
this package".


Then I also found,
http://ubuntu.linux-server.org/mysql-query-browser/mysql-query-browser_1.1.4-1ubuntu2.dsc

[EMAIL PROTECTED]:/tmp$ gpg --verify mysql-query-browser_1.1.4-1ubuntu2.dsc
gpg: Signature made Tue 19 Apr 2005 10:06:56 AM CDT using DSA key ID
C098EFA8
gpg: please do a --check-trustdb
gpg: Good signature from "[EMAIL PROTECTED] <[EMAIL PROTECTED]>"
gpg: aka "shermann <[EMAIL PROTECTED]>"
gpg: aka "Stephan Hermann <[EMAIL PROTECTED]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8

This package was modified from the Debian package (probably as simple as
just rebuilding the automake files because they were quite old). I don't
understand how I could remain as the maintainer of such a package. It is
my belief that if the source code is changed, then the Maintainer field
should be changed as well.

In Debian we do this all the time (NMUs), but Ubuntu is not Debian and
the upload was not to Debian. If there are problems with the Ubuntu
package I cannot fix it yet the problem will be attributed to me (as I'm
the "maintainer").


Anyway, the bottom line is,
1. I'm a Debian Developer and chose to be associated with Debian
2. I have not chosen or gave permission to be associated with
modified/unmodified packages of other distributions (that may or may not
derive from Debian).

What do other DDs think about this problem (or is it even a problem?)?
Personally, I believe Ubuntu must either change the Maintainer field of
all packages such that it points to Ubuntu Developers *or* get
permission to keep the Maintainer field as is from the Debian package
maintainer.

- Adam

PS. This is not a troll against Ubuntu.

PPS. This is not like writing software where the author has a copyright
on the source code and have it displayed. There is a fundamental
difference between "copyright holder" and "maintainer", so please don't
confuse the two.



signature.asc
Description: OpenPGP digital signature

Re: Ubuntu and its "appropriation" of Debian maintainers

[Adam Majer]

Matt Zimmerman wrote:

>On Sat, Apr 30, 2005 at 08:34:09PM -0500, Adam Majer wrote:
>  
>
>>Then I also found,
>>http://ubuntu.linux-server.org/mysql-query-browser/mysql-query-browser_1.1.4-1ubuntu2.dsc
>>
>>[EMAIL PROTECTED]:/tmp$ gpg --verify mysql-query-browser_1.1.4-1ubuntu2.dsc
>>gpg: Signature made Tue 19 Apr 2005 10:06:56 AM CDT using DSA key ID
>>C098EFA8
>>gpg: please do a --check-trustdb
>>gpg: Good signature from "[EMAIL PROTECTED] <[EMAIL PROTECTED]>"
>>gpg: aka "shermann <[EMAIL PROTECTED]>"
>>gpg: aka "Stephan Hermann <[EMAIL PROTECTED]>"
>>
>>
>
>Neither this package, nor the site where you found it, is related to the
>Ubuntu project in any official capacity.  Someone presumably downloaded the
>source package from one of our mirrors, modified it (naively, without
>considering that Ubuntu might release a version 1.1.4-1ubuntu2) and
>published it on their website.  I don't know Stephan Hermann, but you could
>contact him about your concerns.
>  
>
Fair enough. But this package is,

http://archive.ubuntu.com/ubuntu/pool/universe/m/mysql-query-browser/mysql-query-browser_1.1.4-1ubuntu1.dsc

[EMAIL PROTECTED]:/tmp$ gpg --verify mysql-query-browser_1.1.4-1ubuntu1.dsc
gpg: Signature made Mon 28 Mar 2005 01:03:50 PM CST using DSA key ID
A94050AF
gpg: please do a --check-trustdb
gpg: Good signature from "Daniel Holbach <[EMAIL PROTECTED]>"

>>I don't understand how I could remain as the maintainer of such a package.
>>It is my belief that if the source code is changed, then the Maintainer
>>field should be changed as well.
>>
>>
>
>The question of whether modified source should have the Maintainer field
>changed is a reasonable subject for discussion, but in your particular case,
>both of the source packages listed at
>https://launchpad.ubuntu.com/people/adamm/+packages are identical to those
>in Debian.
>
True. But Ubuntu is a *different* distribution from Debian. If Ubuntu
was a Debian subproject, then I see no problem in keeping Maintainer
fields as is.

>>nyway, the bottom line is,
>>1. I'm a Debian Developer and chose to be associated with Debian
>>2. I have not chosen or gave permission to be associated with
>>modified/unmodified packages of other distributions (that may or may not
>>derive from Debian).
>>
>>
>
>In my opinion, it does not make much sense to require Debian derivatives to
>modify every source package that they share with Debian, only to change the
>maintainer field.  There is some justification for changing it if the
>package has been modified, but this, too is problematic (" is
>taking credit for my work!").
>  
>
I think all other distributions based on Debian do change the Maintainer
field. If someone wishes to be a maintainer for Ubuntu (or Kubuntu, or
Gentoo, or Linspire, or RedHat, or ...), then they can apply with a
given distribution.

If Ubuntu maintainers wish to recognize Debian maintainers for their
work, I would welcome that (see below). But the maintainer field should
only reference Ubuntu project. The problems I see is in discussions
(flamewars?) merits of Ubuntu vs. Debian. I've seen in many places
ignorant people saying,

"Most maintainers from Debian are now in Ubuntu", or "Debian is dead.
Ubuntu is the future". Or the opposites from the other side. I didn't
know where this was coming from until I found myself on Ubuntu's website
as a maintainer.

I'm the maintainer of lpr which is from OpenBSD. OpenBSD is acknowledged
in the sources and README.Debian, but I do not set the maintainer field
to point to [EMAIL PROTECTED] or similar.

>>PS. This is not a troll against Ubuntu.
>>
>>
>
>In that case, can I ask why you addressed your concerns to debian-devel,
>rather than to the parties responsible for the web pages you found
>objectionable?
>
>The result (which may or may not have been the intent) seems to have been to
>stir up emotion among Debian developers, rather than to have the Launchpad
>website changed.
>  
>
It is bigger than just that one website as "Maintainer: " field in most
packages that are part of Ubuntu is left same from Debian. I sent the
email to debian-devel maybe because it affects Debian Developers.

http://people.ubuntulinux.org/~cjwatson/germinate-warty-output/all+extra.sources

I see many debian mailing lists... Is it right for a different
distribution to use Debian's support structures?

If Ubuntu recognizes the work of Debian developers, then that is a very
good thing. For example, if, upon conversion, the debian package is
amended to include in README.Ubuntu (or whatever

Re: Ubuntu and its "appropriation" of Debian maintainers

[Adam Majer]

Matthew Palmer wrote:

>I understood the proposal to be only for unchanged Debian source packages
>(ie pure rebuild).  If an Ubuntuite is actively maintaining the package for
>Ubuntu, it stands to reason that they be listed as the Maintainer for the
>Ubuntu source package, with appropriate credit given in the debian/copyright
>(oooh that looks *wrong*) to the Debian maintainer(s).
>
>
IMHO, no credit is required. If Ubuntu just observes copyright by not
removing any copyright notices of the DDs and third parties then that
should be enough. Whenever I want recognition, I just stick a copyright
notice.

Keep in mind that whenever you contribute something back to upstream,
you generally get little recognition for it (at least in my experience).
The code just becomes part of the new upstream version. I'm not too
sensitive about the "recognition" part anyway - I just want the software
to work the way I want it and that's good enough for me.

- Adam



signature.asc
Description: OpenPGP digital signature

AMD64 non-free archive - the good and the bad

[Adam Majer]

Hi,

Ok. Took me about 6 hours, but I think I checked all licenses for
non-free that were in debian/*copyright. I didn't look for other files -
there is too much stuff in non-free and I don't want to go crazy.
Anyway, I compiled the licenses and summary for what Amd64 could
distribute in

http://people.debian.org/~adamm/non-free/

The packages that cannot be distributed (or I think they can't) are in
bad.txt. good.txt contains a list of all packages that have OK licenses
for redistribution. The licenses and script I wrote to extract licenses
are there too.

I was a little bit more liberal with fonts than non-font packages. For
example, if font prohibits redistribution to modification to fonts, but
unmodified was ok, then I said it was ok. If software prohibits any type
of modification (read: it says that) then I deemed it not ok and ended
in the bad.txt. Software with no license in debian/*copyright ended in
bad.txt.

Anyway, I think that packages in good.txt are good to be used by Amd64.

I skipped non-Amd64 capable packages.

For completeness, here's a list of packages which looks OK,

abs-guide
agrep
album
amoeba-data
angband
astrolog
atmel-firmware
autoconf-nonfree
axe
bcm5700-source
bluez-firmware
bsdgames-nonfree
chntpw
ckermit
cl-faq
cl-infix
clustalw-mpi
cmap-adobe-cns1
cmap-adobe-gb1
cmap-adobe-japan1
cmap-adobe-japan2
cmap-adobe-korea1
conserver
core++
crafty
dgen
diablo
doc-html-w3
doc-linux-nonfree
doc-rfc
doom-wad-shareware
dvdrtools
eagle
ebook-dev-alp
ebook-dev-ggad
ebook-dev-kde20
foiltex
gfont
ggobi
gliese
glimpse
gnu-standards
gpcl
grokking-the-gimp
gs-afpl
gs-cjk-resource
gsfonts-other
hevea-doc
hwb
if-transition
inform
iozone3
ipadic
irpas
ldmud
lgrind
lha
libapache-mod-fastcgi
libcwd
libforms-doc
lincvs
manpages-posix
mecab-ipadic
molphy
mpi-specs
mssstest
mysql-nonfree
mysql-nonfree-4.1
newsgate
nttcp
nvidia-graphics-drivers
ocaml-book
ocaml-doc
onlisp
openmotif
opustex
os8
pcx
pgplot5
phylip
picon-domains
picon-misc
picon-news
picon-unknown
picon-usenix
picon-users
picon-weather
povray
povray-3.5
ptex-jtex
python-profiler
qla2x00
rancid
raster3d
revtex
rutebook
scilab
scribus-doc
shapetools-tutorial
snes9x
spectrum-roms
spellcast
spellcast-doc
spim
swt-pocketpc
tads
tome
trn
ttf-gentium
ttf-kochi-naga10
ttf-larabie
ttf-mikachan
tth
ucbmpeg-play
unicorn
uqm-content
w3-recs
w3-recs-2002
w3-recs-2003
wap-wml-tools
xearth
xfonts-scalable-nonfree
xfractint
xgobi
xgobi-doc
xpdf-chinese-simplified
xpdf-chinese-traditional
xpdf-japanese
xpdf-korean
xshodo
xslideshow
xsnow
yale
zangband
zope-book


And here is the list of packages that probably are not OK (some, like
sattrack, CANNOT be distributed without written permission).

abuse-sfx
clustalw
cthugha
ezmlm
festlex-oald
festvox-ellpc11k
figfonts
figlet
fractxtra
hypre
latex2html
lmbench
maelstrom
mmix
moria
mush
netperf
parmetis
pine
qmail
r-cran-mapproj
sattrack
selfhtml
sgb
treetool
trn4
ucspi-tcp
unrar-nonfree
wip
xfonts-naga10
xmame


If there are problems, please, let me know. Now I have to go uncross my
eyes.

- Adam



signature.asc
Description: OpenPGP digital signature

Re: mrtg package problems

[Adam Majer]

Laszlo Boszormenyi wrote:

>Hi,
>
>The mrtg and related packages seems to be orphaned. Shiju p. Nair is
>last done an upload at 2004 April the 6th. Since then, there are only
>NMUs, like it was NMUed constantly since 2002. The package is a bit
>bad shape, would be good if someone look into them; there are even
>seven years old bugs, but well, others are only five or three years
>old. Is there any better package for this task, so mrtg can be
>dropped maybe? But as some bugs have patch included, maybe someone
>else can prepare a bugfixing version.
>On the other hand, I think 2.11.1-1.1 should be pushed to Sarge.
>
>

Currently there are two packages that he maintains,

http://qa.debian.org/[EMAIL PROTECTED]

*libnet**-easytcp-perl
**mrtg

I would like to maintain mrtg since I do use it. As to the other
package, it probably should be orphaned.

Anyway, I will try to take care of the problem. I'll see if I can
contact Shiju and if there is no response by end of the month, I'll
orphan the packages and take over mrtg, unless someone has a problem.

- Adam

*


signature.asc
Description: OpenPGP digital signature

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

[Adam Majer]

Matt Zimmerman wrote:


On Thu, Jun 02, 2005 at 12:25:01AM -0400, Joey Hess wrote:

 


If Debian treated our upstreams this way, I'd be suprised if we ever got
any patches accepted upstream.
   


Debian does, in fact, treat most of its upstreams precisely this way.
Debian publishes a large portion of its changes primarily in the form of
monolithic diffs relative to upstream source.  The last time I saw figures,
the usage of dpatch, cdbs, etc. was rising, but not yet the standard
operating procedure.
 



I know it has been said before, but that is not true. For packages with 
active upstream, I always send individual patches upstream. For packages 
like mysql-admin, or mysql-query-browser, there is no dpatch, etc. used 
because that would be inefficient. Upstream is very fast at fixing 
things and the few, small patches that there are, can be fixed by hand. 
For vast majority of cases, the huge .diff.gz patch is for the /debian 
directory and sometimes to update the config.sub and config.guess files. 
I don't think upstream would wade though .diff.gz files anyway. Huge 
Debian patches like that just make the work of the maintainers, not 
upstream, more difficult.


Low usage statistics for dpatch, cdbs, etc. don't imply that upstream 
doesn't get manageable patches.


- Adam

PS. We already saw that a fork or derivative of upstream can warp into 
something that will waste a lot of man hours to port with the Apple's 
browser (derivative of Konqueror). Their huge patch cannot be easily 
incorporated to the new version of Konqueror meaning that Apple, not 
KDE, will be wasting a lot of their time porting that patch to the new 
versions of the browser. Similarly for non-Ubuntu specific changes, it 
is in Ubuntu's interrest (not necessarly Debian's) to have those patches 
accepted in Debian. I think this is especially true for those critical, 
base packages.



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

Re: C++ ABI change -- freezing unstable for new C++ library packages

[Adam Majer]

Matthias Klose wrote:

> We will send an update with a detailed schedule, when the toolchain is
> ready for the change.


I'm sorry but I'm a little bit confused. Is unstable frozen *now*? If
yes, is the toolchain being updated now?

I'm assuming the change mostly involve moving gcc-defaults to point at
3.4 or 4.0 which I think is possible for all arch at this time [1].
gcc-3.4 is on all arches that I can see.

A much better announcement would be to include some rough estimate on
how long are we going to be waiting for the new toolchain. Is it hours?
days? week? years?

Also, the testing seems to be now unfrozen except for base. Does the
base freeze have anything to do with the new C++ ABI?

Thanks,
- Adam

[1] - http://packages.debian.org/unstable/devel/gcc-3.4


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

Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames

[Adam Majer]

Bill Allombert wrote:

>On Sun, Jun 05, 2005 at 01:25:28PM +0200, Matthias Klose wrote:
>  
>
>>The time frame of the C++ ABI changed is not yet fixed.  We will
>>certainly need some time to get the toolchain in shape to start the
>>transition.  In the meantime you can check the new compilers in
>>unstable (g++-3.4) and in experimental (g++-4.0), the new binutils in
>>experimental (2.16), and the new glibc in experimental (2.3.5).
>>
>>
>
>What is proposed as the default C compiler for etch ? gcc-3.4 or
>gcc-4.0 ?
>  
>

By the time Etch rolls out it could be 2007 (at least early part
thereof) so it will most likely be gcc-4.x. Remember that Woody had gcc
2.95 and Sarge is with gcc 3.3.5.

- Adam


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

Re: kernel security bug #307900

[Adam Majer]

Olaf van der Spek wrote:

> > woody's kernels are vulnerable to CAN-2004-1235, a uselib() race
> condition.
>
> Will this be fixed for Woody?
> I thought the plan was to provide security support for Woody for
> another year?


AFAIK, there is no security support for Woody kernels for some time now.
Use kernel.org and compile your kernels for security sensitive machines.

- Adam



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

Re: C++ ABI change -- freezing unstable for new C++ library packages

[Adam Majer]

Santiago Vila wrote:

>On Thu, 9 Jun 2005, Adam Majer wrote:
>
>  
>
>>Also, the testing seems to be now unfrozen except for base. Does the
>>base freeze have anything to do with the new C++ ABI?
>>
>>
>
>No, it's more a leftover of the freeze process. I asked Steve today
>about this. He says base packages will be unfrozen again in a few days.
>  
>

Ok, thanks! I just wander why weren't all packages unfrozen at once.
Something to do with too much new stuff entering Etch at once?

- Adam


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

Re: namespace conflict != package Conflict?

[Adam Majer]

Sebastian Kuzminsky wrote:

>Hi folks, I have a noob question for you.  I maintain the Cogito package
>(my first), and it wants to install an executable as /usr/bin/git.  The
>GNU Interactive Tools package (git) also wants to install an executable
>as /usr/bin/git.  To avoid this conflict I made cogito Conflict with git.
>
>  
>
Of course this is *seriously* wrong. Why are you preventing people from
using git and cogito together?

>I have been told by Jurij Smakov that this is "seriously wrong", and
>I'm asking for help here.  What's the proper way to handle this situation?
>
>The cogito /usr/bin/git is a tiny little helper script hardly worth its
>inode, but it's in the upstream package and I dont want to remove it or
>rename it.
>  
>
rename /usr/bin/git to /usr/bin/cogito-git or whatever. It is not that hard.

- Adam


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

Re: kernel security bug #307900

[Adam Majer]

Olaf van der Spek wrote:

> Adam Majer wrote:
>
>> AFAIK, there is no security support for Woody kernels for some time now.
>> Use kernel.org and compile your kernels for security sensitive machines.
>
>
> What's the reason for this lack of support?
>
>
I think after Herbert Xu left so did security updates for Woody's kernel,
http://www.mailarchives.org/list/debian-security-announce/msg/2005/00216

- Adam


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

Re: TODO for etch ?

[Adam Majer]

Nikita V. Youshchenko wrote:

>Since I can't find such a list, I'll try to write (a beginning of) one.
>
>- Complete transition to g++ 3.4/4.0 ABI
>- Resolve FDL issue
>- Get Xorg and KDE 3.4 into the archive. [as time passes, the version number
>may change]
>- (?) multiarch
>  
>
I'm not sure about multiarch, but the following will most likely happen,
* Amd64 port officially added,
* The "scc" archive split to lighten load on mirrors for stuff that
only needs one or two mirrors anyway,
* finally get new apt (6.x) included.

There will be a lot of other new stuff in the archive, but I don't think
we will need an official TODO list for that (eg. Qt 4).

- Adam



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

Re: TODO for etch ?

[Adam Majer]

Petter Reinholdtsen wrote:

>>- 
>>
>>
>
> - Improve hardware detection, make sure excluded kernel modules only
>   need to be listed one place.
>  
>
OK. Something to improve uppon.

> - Replace default syslog-daemon to one capable to storing
>   severity/facility in the log file.
>  
>
People can install their own syslog replacement. I don't see a reason
why we need to change something that works now for most people.

> - Change boot system, to one capable of handling dependencies and
>   parallell invocation, to speed up the boot process.
>  
>
Err.. Why? The current "slow" bootup is caused mostly by hardware
detection from my experience. Speeding up hardware detection or remove
it in favour of manual /etc/modules entries would speed up the boot
process a lot more than changing the boot process. If it ain't broke, do
not fix it.

- Adam


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

Re: TODO for etch ?

[Adam Majer]

Jesus Climent wrote:

>On Fri, Jun 10, 2005 at 11:39:16PM +0400, Nikita V. Youshchenko wrote:
>  
>
>>Hello.
>>
>>- 
>>
>>
>
>- Early start of X, while some other stuff is still loading on the bg.
>  
>
That's a single package "problem" so not exactly an Etch todo candidate.
But I think the real problems for slow boots is the hardware detection.

>- get rid of hotplug in its actual incarnation. Is hell of slow and
>  painful.
>  
>
I agree that it is a bit slow :) But again, this is a single package
problem more suited for BTS. For example see bug #309588 where there is
a patch to speed up hotplug.

- Adam


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

Re: TODO for etch ?

[Adam Majer]

On Sat, Jun 18, 2005 at 10:14:27PM -0500, Gunnar Wolf wrote:
> Adam Majer dijo [Wed, Jun 15, 2005 at 01:15:00PM -0500]:
> > > - Change boot system, to one capable of handling dependencies and
> > >   parallell invocation, to speed up the boot process.
> > >  
> > >
> > Err.. Why? The current "slow" bootup is caused mostly by hardware
> > detection from my experience. Speeding up hardware detection or remove
> > it in favour of manual /etc/modules entries would speed up the boot
> > process a lot more than changing the boot process. If it ain't broke, do
> > not fix it.
> 
> My systems have no hardware detection at all - But they start many
> daemons at boot time. Probably, say, Apache and Postgres could be
> started concurrently, saving some extra time.

That could "save" a grand total of about a second. Also, during
startup the bottleneck is the hard drive in many cases so starting concurrently
might not speed up your boot process significantly.

The biggest problem is debugging. Sure, you can fork and start all of
the processes concurrently, but what about if the start fails? You
also want to have some processes started before others so you need
asynchronous instead of synchronous waits... Blah..

Anyway, you can test your maximum speedup like this,

1. Get a list of all the /etc/init.d/ scripts you want to start.
2. Start the sequentially while timing them.
3. Now start them concurrently and time them. When all /etc/init.d/
scripts terminate, that is when you are done.
4. What is the difference?

If you are using bash for this, the easiest way might be to trap
SIGCHLD or something to check when the child terminates.

Alternatively, don't start Apache and Postgres on your workstation to
save a second or two in the boot process. :P

- Adam


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

Re: SONAME and package version question

[Adam Majer]

Roberto C. Sanchez wrote:

>I am working on packaging the ROTE library so that I can depend on it
>for anyterm.  I need to package version 0.2.6 + the CVS from 20050511.
>I have created a patch between the 0.2.6 release and the 20050511 CVS.
>
>Without the patch, the relevant contents of the .deb are:
>
>$ dpkg -c librote0_0.2.6-1_i386.deb
>drwxr-xr-x root/root 0 2005-06-21 22:36:21 ./
>drwxr-xr-x root/root 0 2005-06-21 22:36:20 ./usr/
>drwxr-xr-x root/root 0 2005-06-21 22:36:21 ./usr/lib/
>-rw-r--r-- root/root 13744 2005-06-21 22:36:21 ./usr/lib/librote.so.0.2.6
>lrwxrwxrwx root/root 0 2005-06-21 22:36:21 ./usr/lib/librote.so.0 -> 
>librote.so.0.2.6
>
>With the patch, the relevant content are:
>
>$ dpkg -c librote0_0.2.6+20050511-1_i386.deb
>drwxr-xr-x root/root 0 2005-06-22 10:48:51 ./
>drwxr-xr-x root/root 0 2005-06-22 10:48:51 ./usr/
>drwxr-xr-x root/root 0 2005-06-22 10:48:51 ./usr/lib/
>-rw-r--r-- root/root 13744 2005-06-22 10:48:51 ./usr/lib/librote.so.0.2.7
>lrwxrwxrwx root/root 0 2005-06-22 10:48:51 ./usr/lib/librote.so.0 -> 
>librote.so.0.2.7
>
>Is it OK for the last digit in the library to change from 6 to 7?  Do I
>need to do something about the version number?
>  
>
The soname doesn't appear to have changed. It appears to be
librote.so.0  The other parts are not part of the soname, just the filename.

Of course, I'm assuming that upstream knows what they are doing and not
just having soname=version and deleting or changing interfaces in the
library. Some upstream are clueless that way.

You will also need to be careful about when you run dh_makeshlibs if you
manually set the version numbers.

- Adam


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

Re: Work-needing packages report for Jun 24, 2005

[Adam Majer]

Anibal Monsalve Salazar wrote:

>On Fri, Jun 24, 2005 at 12:26:30AM -0600, [EMAIL PROTECTED] wrote:
>  
>
>>The following packages have been orphaned:
>>
>>
>>
>
>It seems to me that bugs #314682 and #314683 are broken.
>  
>
Ok, thanks. They are unbroken now.

- Adam



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

Re: should etch be Debian 4.0 ?

[Adam Majer]

Drew Parsons wrote:

>I suppose we should decide now if etch is going to be 3.2 or 4.0.
>
>Given the ABI change with gcc-4.0 and the introduction of X.org, it
>seems to me we have ample justification to introduce Debian 4.0.
>  
>
We had an ABI change with Sarge as well. Also, there is not that much
difference between X.org and XFree86. Well, less than with 3.x and 4.x
branches of X.

I'd we we should not start going the way Red Hat or Suse went with
version numbers and should follow more closely what Mac OS is now doing.
Their releases are 10.0, 10.1, 10.2, 10.3, 10.4, etc...

Anyway, as someone already said, going multiarch would warrant Debian
4.0. Some applications being udpated does not warrant that, IMHO.

- Adam



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

Proper way of closing *old* bugs

[Adam Majer]

Hello everyone,

I've written an email to Cyril Bouthors that started as,


"In your 4.0.0-3 upload of gluplot, you've said in the changelog

 * This upload is aimed to take over the package and fix the easiest bugs
   first. I'll upload another version shortly that will take care of the
   oh-so-many opened bugs that look almost all fixed upstream and/or
   obsolete to me. One of them is 5 years and 160 days old! "Release
   early, release often".
"

The rest of the email and his response follows,

Cyril Bouthors wrote:
> On  3 Apr 2006, Adam Majer wrote:
>
>   
>> But the correct method of closing bugs is to send a message to
>> [EMAIL PROTECTED] with the explanation of the fix and not in
>> the changelog. Well, at least not in the way you seem to intend. The
>> bugs closed in changelogs are suppose to be bugs closed due to the
>> changes from the previous version to the current version. If you only
>> mean to do,
>>
>> * Close bugs that were fixed VERY long time ago (closes:
>> #123,#234,#345,#456,#567,#678,#789,)
>>
>> then I don't think that is appropriate use of the changelog.
>> 
>
> Closing bugs through the changelog is an officially supported method
> and most DDs close bugs that way. Submitters receive a detailed
> notification by email as soon as the package is uploaded.
>
> I have no special mean to close bugs without informing the submitters
> with a clear and detailed explanation as I always did with all my
> packages.
>   



My question is, is it now appropriate to use the changelog as a crutch
to close bugs that have nothing to do with the upload? I was always
under impression that *old* bugs should be closed by sending an email to
[EMAIL PROTECTED] saying that you are closing it because it was
fixed some time ago, etc.. etc..

The policy [1] states,

"If this upload resolves bugs recorded in the Bug Tracking System
(BTS), they may be automatically closed on the inclusion of this package
into the Debian archive by including the string: closes: Bug#n in
the change details."

Therefore, by my reading of the policy the changelog is not an
appropriate method of closing *old* bugs because they were not resolved
by the upload. They were resolved some time ago and should be closed by
a mail to the BTS.

- Adam

[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog



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

Bug#291732: ITP: rake -- a simple ruby build program with capabilities similar to make

[Adam Majer]

Package: wnpp
Severity: wishlist
Owner: Adam Majer <[EMAIL PROTECTED]>

* Package name: rake
  Version : 0.4.14
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://rake.rubyforge.org/
* License : MIT
  Description : a simple ruby build program with capabilities similar to 
make
 Rake is a simple ruby build program with
 capabilities similar to make.
 .
 Rake has the following features:
   * Rakefiles (rakes version of Makefiles) are completely defined in
 standard Ruby syntax. No XML files to edit. No quirky Makefile
 syntax to worry about (is that a tab or a space?)
   * Users can specify tasks with prerequisites.
   * Rake supports rule patterns to sythesize implicit tasks.
   * Rake is lightweight. It can be distributed with other
 projects as a single file. Projects that depend upon
 rake do not require that rake be installed on target
 systems.



License

Rake is available under an MIT-style license.

Copyright © 2003, 2004 Jim Weirich

Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Re: Debian conference in the US?

[Adam Majer]

On Sat, May 24, 2003 at 07:46:53PM -0400, Geordie Birch wrote:
> On Sun, May 25, 2003 at 03:32:57AM +1000, Russell Coker wrote:
> > 
> > For avoiding entering the US there are better reasons such as the following:
> > http://www.informationclearinghouse.info/article1689.htm
> 
> May 20, 2003.  French reporters covering Electronic Entertainment Expo (E3) 
> arrested, forcibly repatriated:
> http://www.theinquirer.net/?article=9609
> http://www.rsf.org/article.php3?id_article=6909

Oh my god. The last time I heard this was the "shocking" news from 
Baghdad when CNN got thrown out by Saddam for not having the "new"
press visas.

There are even reports that Canadian citizens that have darker
skins are discriminated against. There was one _Canadian_ citizen
that got arrested in the US because he didn't have a visa

[NOTE: Canadians do not need visas to enter US and vice versa]

He was then deported to Sudan because apparently he immigrated
from there to Canada a two or three decades ago.


My parents got searched _twice_ (yes, including shoes!!) in the
states. They were going back home from Europe and they 
had to catch a connecting flight in Miniapolis, Minnesota.


Maybe it's just me, but it appears that people have less freedom
now if they travel to US, then when you travelled to 1970s
Soviet Union. "Land of the free", lol.

- Adam

PS. Personally, I would prefer to travel for a DebConf in
Cuba than in US. Really.

Re: Debian conference in the US?

[Adam Majer]

On Sun, May 25, 2003 at 03:36:39PM -0400, Jaldhar H. Vyas wrote:
> On Sat, 24 May 2003, Adam Majer wrote:
> 
> > PS. Personally, I would prefer to travel for a DebConf in
> > Cuba than in US. Really.
> >
> 
> So let me get this straight.  Instead of a country where people are
> occasionally subject to bureaucratic hassles, (assuming Russell and
> Geordies' sources amount to anything more than innuendo which is not
> clear.) you would rather go to a place where the immigration policy
> consists of shooting people?

s/Immigration/Emigration/ ? You do realize that US is pretty much the
only country that still has an embargo againt Cuba? Of course they
would not do the same to China.. H.. And why could that be?

2 commandments of Politics:
  1. follow the money
  2. see #1

Anyway, this is getting very off-topic Back to Debian. A!!

- Adam

Re: Help wanted for packaging postgresql application

[Adam Majer]

On Sun, May 25, 2003 at 04:50:03PM -0400, Matt Zimmerman wrote:
> On Sun, May 25, 2003 at 09:56:04PM +0200, Andreas Tille wrote:
> 
> > I want to package GnuMed which is a Python application accessing
> > PostgreSQL server.
> > 
> >  http://bugs.debian.org/166282
> > 
> > It comes with a Python bootstrap routine.  That means the postinst script
> > would need a working Python and PostgreSQL server installed.
> > 
> > I think I would solve this by a simple check whether Python and PostgreSQL
> > are working. If not I would use a Debconf message to tell the user, what
> > to do after installation of all prerequsites is done.  If there is any
> > better way to accomplish this I would be happy for hints.
> 
> For python, you only need to declare Depends: python to ensure that python
> is installed and configured when your postinst runs.

Wouldn't you need predepends?

Re: ATI Linux Driver Packages

[Adam Majer]

On Sun, Jun 01, 2003 at 09:42:10PM -0500, Chris Cheney wrote:
> Are these drivers much better then than XFree ones or is there a reason
> to be promoting nonfree drivers? I orginally packaged up the nvidia ones
> in the way they are done due to the fact the XFree ones had no 3d
> acceleration at all and that it was illegal to distribute nvidia's
> binaries directly.  Also binary only drivers will taint the kernel and
> can cause the user to have trouble getting help with kernel related
> issues. I got rid of my nvidia cards (some poor sucker took them) and
> now use only ATI cards. 8)

I think you might be the "sucker". :) [ok, it's not a flame thing].
Does the radeon driver support 3D accel for cards beyond the R1xx level?
ie. something like Radeon 7500. I don't think that Radeon 8500, 8800, etc..a
are supported since they use the former FireGL GPU. The drivers from
ATI fill the gap to support FireGL, and yes they are better. They
can be used with Maya etc.. [at least it says that on ATI's site.]

BUT, ATI doesn't have any drivers for new cards like Radeon 9800 and I 
do not think they will have any Linux drivers.

On the other hand, I installed Debian for a frried and he had a 
GeForce 4 MX card. The driver from nVidia worked perfectly.
Futhermore, I think that they only distribute the X driver that's 
precompiled. The kenrel part has to be compiled by hand (which is good).

Futhermore, I believe that nVidia have _much_ better support in X
from nVidia than radeon ever had from ATI. The free 3D driver
hacked together does not give good performance as does nVidia's
propriatory driver. Frankly, I very much prefer that nVidia has
in-house support for their cards while ATI has none (the ones for
Radeon 8500, 8800, etc.. are just FireGL drivers).

Of course if you only use 2D stuff, you can stick with some $20 card
and be fine.

- Adam

Re: Bug#198158: architecture i386 isn't i386 anymore

[Adam Majer]

Sebastian Kapfer wrote:
I'd drop the sub-pentiums (i.e. 386 and 486) entirely. Not that my vote
would count...
I once read somewhere that you should _never_ compile in 486 
optimizations for use in processors other than the 486. Apparently
since 486 optimized code is padded a lot with NOPs.

Apparently you are much better off on a Pentium or Athlon with
i386 optimized code than i486 optimized one.
Hence if we are going to migrate from i386, we should not
go to CPU like i486 and just move to a Pentium Classic
code (i586).
- Adam
PS. ASAIK, i486 is very similar to i386 if you compare them to a i585
processor. Not too many new instructions there.

Bug#198158: architecture i386 isn't i386 anymore

[Adam Majer]

On Mon, Jun 23, 2003 at 12:41:48PM -0500, John Goerzen wrote:
> On Mon, Jun 23, 2003 at 08:00:07PM +1000, Herbert Xu wrote:
> > John Goerzen <[EMAIL PROTECTED]> wrote:
> > Talk is cheap.  If you can come up with a solution to the C++ problem that
> > ignited this debate then i386 would be safe.
> 
> Nobody has even explained WHY we have this issue.  The summary posted on the
> bug report just said that there is a problem with atomicity.h, not what the
> problem is or why it exists.

Where is automicity.h?

Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)

[Adam Majer]

On Wed, Jun 25, 2003 at 12:47:41AM +0100, Andrew Suffield wrote:
> On Tue, Jun 24, 2003 at 11:15:42AM -0700, Keegan Quinn wrote:
> > On Tuesday 24 June 2003 10:59 am, Emile van Bergen wrote:
> > > Hi,
> > >
> > > On Tue, Jun 24, 2003 at 11:44:51AM -0500, Adam Heath wrote:
> > > > Tell me when you upload this, so I can file an rc bug against it, for
> > > > modifying other packages conffiles.
> > >
> > > *g*
> > >
> > > 5 serious replies already -- sorry Adam, I'm afraid there are just too
> > > many people that lack even the most basic sense of humour.
> > 
> > Or perhaps not everyone thinks a threat of an RC bug is a laughing matter.
> 
> Sure, people who have sticks up their arses don't. Mocking them is
> great fun.

Are you on crack or you rotated on one of your "arse sticks" one too 
many times when you wrote this? Maybe most people lack some perverted sense of 
humor.
And if that was a joke, thank god he's not going into stand up comedy.

Re: Application files in $HOME

[Adam Majer]

On Wed, Jun 25, 2003 at 02:02:04PM -0300, Daniel Ruoso wrote:
> Hi,
> 
> Recently I had a problem of exceeded quota in my home directory, so I
> went cleaning it, and I saw many and many files and directories with
> configurations for applications that I've runned in the past, but that 
> packages were purged from my system a long time ago, so what is the idea
> (that can be a proposal)?
> 
> What if the packages tells to dpkg which files or directories it will
> create on the user's home directory and when a package is purged the
> user could run a program to purge the files of packages that no longer
> exists. This will also help to know what these files means after all, I
> thought about a browser to inspect application's files in my home, so it
> will be easier to decide which files I don't want anymore...
> 
> What is needed?
> 
> The packages should have a control file (like conffiles) that tells
> which files this package will create.
> 
> A repository to store this information so the user can browse it.
> 
> A userconfpurge program that the user runs to remove purged packages
> configuration files
> 
> A browser to associate the files with the packages and manage them (so
> the user can tell: I don't use icewm anymore, please remove it's
> configuration files).
> 
> Is there risk involved?
> 
> I don't know if different packages create conf files with the same name,
> if it does so, it would be necessary to avoid this practice.

This would require a lot of work on the part of each maintainer to see
which files get created where. One would need to change the Policy as well
to require maintainers to actually use such a "registry".

I say it is not worth it. Just do a `ls -la` and delete the really old
stuff that you know you don't need. Or even better, add yourself as 
a new user to the system, copy all the stuff you need from the old
account, and when ready, remove the old account with all the directiries :)

- Adam

Re: NM non-process

[Adam Majer]

On Wed, Aug 06, 2003 at 04:58:17AM +0200, Goswin Brederlow wrote:
> Kalle Kivimaa <[EMAIL PROTECTED]> writes:
> 
> > Roland Mas <[EMAIL PROTECTED]> writes:
> > > with.  The MIA problem is significant enough that NM might be the only
> > > way to tackle with it seriously.  That means taking time to examine
> > > applications.
> > 
> > BTW, has anybody done any research into what types of package
> > maintainers tend to go MIA? I would be especially interested in a
> > percentage of "old" style DD's, DD's who have gone through the NM
> > process, people going MIA while in the NM queue, and people going MIA
> > without ever even entering the NM queue. I'll try to do the statistics
> > myself if nobody has done it before.
> 
> And how many NMs go MIA because they still stuck in the NM queue after
> years? Should we ask them? :)

I'm stuck since Dec. 2001 FOR THE LOVE OF GOD!!! SOMEONE HELP 
ME!!! HELP ME SEE THE LIGHT AT THE END OF THE NM TUNNEL!! AGGG!!! 

Oh well, this "plea" probably will go the way of the weekly RC bug 
report - ignored.. :)

Since I started waiting for DAM, I saw a number of "DD"s get 
approved by their AM and accounts created, only later to go MIA 
Maybe it is better for them to go MIA in the NM queue in the first place? 

- Adam

My definition of MIA for DD: Doesn't fix release critical bugs for his/her 
package(s) within a week or two and doesn't respond to direct emails
about those bugs.

Re: NM non-process

[Adam Majer]

On Wed, Aug 06, 2003 at 12:40:21PM +0200, Goswin Brederlow wrote:
> Tollef Fog Heen <[EMAIL PROTECTED]> writes:
> 
> > * Adam Majer 
> > 
> > | My definition of MIA for DD: Doesn't fix release critical bugs for
> > | his/her package(s) within a week or two and doesn't respond to
> > | direct emails about those bugs.
> > 
> > I guess I'm MIA, then, since I have an RC bug which is 156 days (or
> > so) old, which is waiting for upstream to rewrite the program.
> 
> Taged forwarded?

When you have maintain a package, shouldn't you be able to fix
it yourself?

IMHO, people should not package or take over a package that they
do not understand how it works. For example, a kernel maintainer
should be a kernel developer. Or a Qt maintainer, should at 
least use Qt on dailly basis - preferably both commercially and/or 
for free software.

People should maintain packages they are qualified to maintain
and not becuase "it would be neat to package that!".

Sometimes you get really hairy bugs that even qualified 
developers would have trouble to fix... then you need to holer
for help until somone helps... Isn't there a tag for
Help Wanted or something?

- Adam

Re: About NM and Next Release

[Adam Majer]

On Wed, Aug 06, 2003 at 04:27:24PM -0500, Joe Wreschnig wrote:
> On Wed, 2003-08-06 at 14:32, Steve Lamb wrote:
> > Except when your sponsor goes AWOL for 3 weeks after giving them the URL
> > to download the packages to paw through and upload.
> 
> This is not different than someone in your path-to-Linus being AWOL. It
> happens.

Don't you just post a [PATCH] to the kenrel-devel mailing list??
Then Linus applies it or not.

Re: NM non-process

[Adam Majer]

On Thu, Aug 07, 2003 at 08:18:00AM +1000, Matthew Palmer wrote:
> On Wed, Aug 06, 2003 at 11:58:22AM -0500, Adam Majer wrote:
> > IMHO, people should not package or take over a package that they
> > do not understand how it works. For example, a kernel maintainer
> [...]
> > People should maintain packages they are qualified to maintain
> 
> Well, I see you're taking your own advice to heart.

Yes I am. I don't see any RC bugs about my packages :) Find one and I'll
fix it if upstream doesn't (or hasn't).

Sometimes packages are teminally broken (likes jikes 1.16 or 1.17)
in which case it is better to downgrade than upgrade.

- Adam

PS. If any bugs against my packages bother you very much, tell me
(and why is it critical for you) and I'll see what I can do. The
largest problem for me is time - for next few days I have a large
project to complete.

The only package that I may not be qualified for is Jikes. And that's
because I don't know the internals of JVM and Java opcode...
or *all* the internals of Jikes... I'm thinking of filling a RFA: on
jikes. But it is still better than it being O: like it was
for some time before I picked it up.

Re: About NM and Next Release

[Adam Majer]

On Wed, Aug 06, 2003 at 08:28:26PM +0100, Andrew Suffield wrote:
> On Wed, Aug 06, 2003 at 08:39:52PM +0200, Oliver Bausinger wrote:
> > > Someone should point NMs to difficulty of entering the development
> > > mainstream of FreeBSD or becoming maintainer for the kernel...
> > > IMO it's generally too easy entering in Debian.
> > >
> > 
> > And someone should point the DDs to the difficulty of entering KDE. 
> > I sent only and handful of patches, then asked for a CVS account and got it 
> > within two days. KDE is a wonderful example of encouraging people.
> 
> I am so glad I don't run KDE.

Me too!!

I guess it only takes a few patches to introduce "bugs" into KDE. Lol.
They are going to get burnt someday real bad if they continue with that
policy.

- Adam

Re: About NM and Next Release

[Adam Majer]

On Wed, Aug 06, 2003 at 02:38:34PM -0500, Adam Heath wrote:
> On Wed, 6 Aug 2003, Chris Cheney wrote:
> 
> > On Wed, Aug 06, 2003 at 01:41:45PM -0500, Adam Heath wrote:
> > > On Wed, 6 Aug 2003, Chris Cheney wrote:
> > >
> > > Not to toot my own horn, but I was accepted in under one week.  I took 2 
> > > weeks
> > > to read up on everything, then after I sent in my app, less than a week 
> > > later
> > > I was accepted.
> > >
> > Yep, this was before NM was closed indefinitely. From sometime around
> > early 1999 until mid 2000 (June iirc) NM was closed, as far as I know
> > no one at all was accepted into Debian during this time. IIRC Wichert
> > finally got the ball rolling to start accepting new maintainers around
> > April 2000.  I don't know the current average time for a NM to get
> > through the queue but I would guess at it being around 3-4 months.
> 
> My mail was not an attempt to compare pre-NM acceptance times to after.  It
> was to show that those who do work, get accepted.

I guess, eventualy I maintain 10 sources in main - none have RC bugs.
Waiting since, well, about Dec 2001... Interresting...

>From my experience, you last sentance is true only if you do not make
any mistakes. For example, when I applied I took over some O:
packages - most were O: for a long time (in Dec. 2001). Note that
a lot of them were broken at that time and upstream, well, :)

eg. yiff

I updated it, but not knowing much about sonames (eg. when to change
them to what when upstream doesn't have a clue about them and just
sets them to version number), I messed up packaging of
yiff. Few RC bugs later, I learnt about sonames and fixed the
bug. But the damage was done - AM told me to learn more about
sonames! *BUT* I already learnt all about sonames from the mistakes
I've done that were reported to me. About a year later, I 
was finally approved by AM (I guess both of us dropped the ball
on that).

So what is the moral of the story for NM?

DO NOT PACKAGE A LIBRARY IF YOU DO NOT KNOW EVERYTHING ABOUT SONAMES!

You can *after* you become a DD and screw up then. But not before.


Anyway, waiting for DAM for some months now. I guess it has been
4-5 months now. I asked him on IRC when he might get arround to
my application, but he just said when he has time...


But I have no complains.. well, maybe except that every week or two
the parties responsible for the applicant (eg, AM or DAM) should
send out a status reports or something. That way there would be 
less stagnation in the entire process. Why? Because people want to
do least amount of work to do their job. Just a suggestion.

- Adam

Re: About NM and Next Release

[Adam Majer]

On Thu, Aug 07, 2003 at 09:47:38AM +0200, Goswin von Brederlow wrote:
> Adam Majer <[EMAIL PROTECTED]> writes:
> 
> > On Wed, Aug 06, 2003 at 02:38:34PM -0500, Adam Heath wrote:
> > Anyway, waiting for DAM for some months now. I guess it has been
> > 4-5 months now. I asked him on IRC when he might get arround to
> > my application, but he just said when he has time...
> 
> He actually replied?
> 
> I saw him talking on irc and thus knew he was around and
> breathing. But not even a "bugger off" reply when I asked him.

Maybe you didn't ask right :) But you will probably get the same
response as I got - he'll get arround to it when he has time.

> > But I have no complains.. well, maybe except that every week or two
> > the parties responsible for the applicant (eg, AM or DAM) should
> > send out a status reports or something. That way there would be 
> > less stagnation in the entire process. Why? Because people want to
> > do least amount of work to do their job. Just a suggestion.
> 
> A simple timestamps on the application webpage showing the last time
> the AM or DAM did anything with the application would be a plus
> already.

But *if* the DAM or AM would need to write a status report every
week or two re: applications they are responsible for, there would be a 
tendancy to
either:
  1. reject the applicant (eg. when applicant doesn't reply to 
   email or doesn't know what make does)
  2. accept the applicant

And the reason for that is because people don't want to write reports!

Re: Bug#462027: ITP: libactiverecord-ruby -- library that ties database tables to classes in Ruby

[Adam Majer]

Jon Dowland wrote:
> On Mon, Jan 21, 2008 at 09:35:06PM -0500, David Nusinow wrote:
>> Have you spoken with the rails package maintainer about this and your
>> other ITP? Having duplicate copies of the same code lying around in
>> the archive is something the security team has said they are actively
>> discouraging.  Splitting these out from the rails package seems like
>> the smarter way to go.
> 
> As a complete third-party, I'd be mildly interested in having
> activerecord as a separate package from rails in it's entirety.

Why? What is the disadvantage of having it together with rails? I'm
assuming 7MB of diskspace (2MB archive) is not what is your main reason.

- Adam


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

Re: DD in Antarctic Continent?

[Adam Majer]

Roberto C. Sánchez wrote:
> On Sun, Mar 09, 2008 at 02:17:04PM -0400, Clint Adams wrote:
>> On Sun, Mar 09, 2008 at 05:13:14PM +0100, Lionel Elie Mamane wrote:
>>> So he's really in very-northern Finland/Sweden/Norway/Russia?
>> If I recall correctly, he was somewhere in or around Michigan.
>>
> Which really is not all that different from very-northern
> Finland/Sweden/Norway/Russia :-)

If state like Michigan is far north, then where is Canada?? :)

To put it in perspective, Michigan is at the same latitude as northern
half of Italy or even Spain. I would not say these are the northern tip
of Europe...

Most of Canadians live south of the latitude of London, UK.

- Adam


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

Re: Is master unsuitable to receive mail from lists.debian.org?

[Adam Majer]

Colin Watson wrote:
> Yes, I've been seeing the same thing. It's usually just an irritation,
> but I guess some day I'll hit a threshold and get unsubscribed from a
> bunch of lists.

Wouldn't it be possible to configure the mail server to filter the mail
based on the header content? That is,

 * Is it spam? => Yes => Now do the following:

   1. If mail from a mailing list or precedence Bulk or has List-Id in
headers, discard it
   2. Reject with 5xx - Spam

This is kind of what I have setup postfix to do except I filter based on
source IP - could be easier to setup in master's case. If mail is from a
known mailing list server (eg. debian, sourceforge), it gets accepted
and processed in a post queue filter with spam being dropped. If mail is
not from a known mailing list server, it goes to default configuration
which does pre-queue filtering where spam is rejected with 5xx SMTP
level message.

I'm sure it would be possible to set it up based on the existence of
Priority: Bulk or List-Id: headers.

The only side effect is sometimes the number of connections are more
than the server can filter, but that is not generally a significant
problem. It just means the connection is delayed for a few minutes.

- Adam


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

Re: Split a package, rename an init file

[Adam Majer]

Bertrand Marc wrote:
> Hello,
> 
> I'd like to split a package foo into 2 new packages : foo and
> foo-daemon. To do that I moved the daemon and the other obvious files
> with dh_install -pfoo-dameon. I used dh_installinit to install the
> init.d file to the foo-daemon package.
> 
> Here are my questions : what am I doing wrong ? How can I remove the
> /etc/init.d/foo unnecessary file ?

No, you can't just remove /etc/init.d/foo. It is a conffile and may be
modified by admin. You should probably keep /etc/init.d/foo instead of
renaming it foo-daemon.

> 2 things : I'm an not on debian-devel, and in this case foo = fglrx-driver

Will foo depend on foo-daemon? If yes, why are you splitting the package?

- Adam


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

Re: Split a package, rename an init file

[Adam Majer]

Bertrand Marc wrote:
> Thanks for your answers!
> 
> So I guess the best way to do this is to split the package and use
> dh_installinit --name=foo
> 
> This way I can provide the buggy binary daemon in a seperate package
> (recommended by foo), and keep the name of the conffiles.
> 
> Do you think of something else?

So the fglrx driver works fine *without* the daemon?

- Adam


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

Re: ssl security desaster

[Adam Majer]

Russ Allbery wrote:
> Martin Uecker <[EMAIL PROTECTED]> writes:
> 
>> In this case, the security advisory should clearly be updated. And all
>> advise about searching for weak keys should be removed as well, because
>> it leads to false sense of security. In fact, *all* keys used on Debian
>> machines should be considered compromised.
> 
> All *DSA* keys.  RSA keys do not have the same problem, as I understand
> it.

Err, how so??

RSA keys generated with broken OpenSSL need replacing. This means SSL
certificates, CA, etc

But RSA keys (for SSL, as an example), generated on good OpenSSL but
used on Etch servers are ok?

- Adam


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

Re: How to handle Debian patches

[Adam Majer]

Josselin Mouette wrote:
> Le vendredi 16 mai 2008 à 16:04 -0400, Joey Hess a écrit :
>> You're insinuatiog that a VCS does not allow easily browsing and
>> examining patches, and I just don't buy it.
> 
> I can do more than insinuating: a VCS does not allow easily browsing and
> examining patches. It doesn’t prevent it, but solely, it is not
> sufficient.

git.debian.org

Seems very clear to me. Same patch changes as upstream for small
projects like Linux.

Clear patches are not because of VCS, but because of clear and concisely
described changesets. If you have patches with bad descriptions or a
giant blob in VCS, then that is useless not because of the failure of
VCS, but the failure of the developer.

Cheers,
Adam


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Adam Majer]

Patrick Schoenfeld wrote:
> In my humble opinion they should be allowed to be packaged as if they
> are normal packages. Don't get me wrong, but Debian is a distribution,
> so what we basically do is pack up things that are worth distributing
> and distribute them. This way Debian users can benefit from our work and

AFAIK, we do not distribute "things", we distribute *software*. Some
packages are just composed of data though, but other packages depend on
it. Some is just data that is very useful in the *Debian* project. This
includes the keyring.

Certainly, the backports.org keyring is useful to some people, *but* it is,

  1. not free software
  2. free software does not depend on it
  3. not part of Debian's important data stuff

If backports.org keyring get distributed, then I would argue it allows
others, non-software data to be packaged as well. For example, some free
anime movies, or the Gutenberg project packages.

Debian is for *free software* (and some non-free) and stuff that related
to Debian. It is not for backports.org, or Ubuntu, or some other stuff.

- Adam


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

Re: Build logs from local builds

[Adam Majer]

On Wed, Oct 21, 2009 at 01:27:05PM +0200, Samuel Thibault wrote:
> I confirm that usually not having the i386 or amd64 log is often a
> problem.
> 
> One idea that was floating around was to have buildd always recompile
> the package, even on archs the uploader has provided a binary version
> for, to make sure packages are clean.  That would somehow answer you
> need (i.e. provide a build log for _all_ archs).

Or here's a radical idea - allow source only uploads of packages.

People are lazy and like myself don't want to sync pbuilder and
related stuff every time I want to upload something. Since my box is
rarely up to date, this can result in dependencies lagging
somewhat compared to official buildd. I generally don't check for any
build-depends problems anyway with pbuilder unless buildd chokes.

And for the Arch:all packages? I guess no check for this with lazy
maintainer.

So how do I compare with the other maintainers? Or do all maintainers
run pbuilder religiously for each upload?

The requirement not allowing source only uploads is childish at best -
it treats DD as children that can't check their packages compile on
their own box.

I'm all in favour of removing uploaded binaries. But also allow source
only uploads.

-- 
Adam Majer
ad...@zombino.com


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

Re: Proposed mass prototypejs bug filing for multiple security issues

[Adam Majer]

On Sun, Oct 18, 2009 at 08:43:35PM -0400, Michael S Gilbert wrote:
> Here are the affected source packages:
> - rails  (embed)

~$ apt-file list rails | grep prototype.js
rails:
/usr/share/rails/actionpack/test/fixtures/public/javascripts/prototype.js
rails: /usr/share/rails/railties/html/javascripts/prototype.js

-rw-r--r-- 1 root root 15 2009-09-21 13:03
/usr/share/rails/actionpack/test/fixtures/public/javascripts/prototype.js

lrwxrwxrwx 1 root root 45 2009-09-21 13:38
/usr/share/rails/railties/html/javascripts/prototype.js ->
../../../../javascript/prototype/prototype.js


This is from rails in testing/sid. In stable the package depends on
the prototype package too. I'm not sure how you get the "unfixed" and
(embed). Seems a little rushed.

- Adam


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

Re: Build logs from local builds

[Adam Majer]

On Wed, Oct 28, 2009 at 07:12:15AM +0100, Stefano Zacchiroli wrote:
> On Mon, Oct 26, 2009 at 02:29:47PM -0500, Adam Majer wrote:
> > Or here's a radical idea - allow source only uploads of packages.
> 
> He, radical, but not new :) It has been discussed to death various
> times. The most likely (and IMO better) alternative to that is uploading
> binaries but trowing them away for autobuilding. If you hold your breath
> just a bit more, it might be happening soonish [1,2]. And thanks to the
> FTP masters for their work on this!

It is *one* way of making sure the archive is consistent. But the idea
behind source-only is to remove the necessity of uploading giant
binaries if they are to be tossed anyway. For example, OpenOffice
revisions, or Linux kernel revisions, or even  Qt revisions.

The bottom line is trust. You trust developers to take
care of packages, more or less. You trust developers NOT to insert any
malicious code (be it DD or upstreams). You trust developers to
actually use the packages they upload, at least from time to time, so
they know how to respond to bugs. But you do not trust developers to
actually compile the package in the first place? That seems a little
out of place.


Now as to address some flabbergasted responses I've received to my
original post, it was merely an illustration how this stuff actually
*works*. There is a lot of dirt that gets swept underneath the rug, so
to speak. Just look at any large package's bug reports. You'll notice
the HUGE amount of bugs that are not closed and not followed.

And regarding build-dependencies, why people tend to keep adding and
adding build depends and rarely remove stuff that is not needed
anymore? No need to answer.

- Adam


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

Re: Build logs from local builds

[Adam Majer]

On Tue, Nov 10, 2009 at 11:27:39PM +0100, Bernd Zeimetz wrote:
> Adam Majer wrote:
> > People are lazy and like myself don't want to sync pbuilder and
> > related stuff every time I want to upload something. Since my box is
> > rarely up to date, this can result in dependencies lagging
> > somewhat compared to official buildd. I generally don't check for any
> > build-depends problems anyway with pbuilder unless buildd chokes.
> 
> And so you put the problem on the shoulders of the buildd admins. Sorry, but
> that behaviour makes me choke. I've CCed DAM as this behaviour is absolutely 
> not
> acceptable for DDs.

 <<<<   <-- my comments

  O
 /|\<-- you
 / \

My comments are merely an example of how stuff works. Since you are
too young in Debian, let me recap a period in Debian when source
uploads were actually accepted and I have used them on occasion. It
addressed various dependency lags, generally on the buildd. As you may
imagine, sometimes buildd are not updated with latest and greatest
because of problems in the said versions.

Now, source uploads resulted in people abusing the source only upload
and uploading packages that don't actually build. And by that, I mean
packages that do not build without tweaks. So, they disabled source
only uploads to *force* people to actually build a package. Of course,
this does not stop people from uploading packages that FTBFS. And what
ended up as a problem that we have now? Lagging dependencies. Exactly
the problem that is fixed by source-only uploads.

The current solution is to "imitate" source only by dropping all
binary uploads. So why not have source only upload from developer's
machine directly?

As I alluded in another reply, in Debian you are trusted to,

  * package software that is usable
  * not to break people's computers
  * not to inject malicious code into software
  * not to abuse Debian machines accessible to you
  * use the software you package and test it for usability

but at the same time you are not trusted enough to *compile* code on
your machine? That's the problem I have with not allowing source only
uploads - the trust is broken at the most insignificant part of the
process.

If people really want to be pedantic about this, why not allow uploads
of the source and skip the *.deb at the dev's machine?? The signed
.changes includes proof that the *.deb were built so why require the
actual *.debs to be uploaded?




> > I'm all in favour of removing uploaded binaries. But also allow source
> > only uploads.
> 
> No way. At least to stop people like you who prefer to let the buildd admins 
> do
> *your* work.

Please think carefully, *carefully* about what you are talking about
because what you write here, it makes no sense.

- Adam

PS. Please don't spam DAM's mail box. It probably gets enough spam.


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

Re: Build logs from local builds

[Adam Majer]

On Mon, Oct 26, 2009 at 02:58:19PM -0500, Manoj Srivastava wrote:
> On Mon, Oct 26 2009, Adam Majer wrote:
> > Or here's a radical idea - allow source only uploads of packages.
> 
> And thus allow people to upload without ever building locally.

I would expect people to build packages locally. How else can they
install then? How can they test them otherwise?

What about ditching *.deb before the upload? dput and related upload
as they do now but ignore *.deb. Archive requires that .debs are in
.changes but does not check for their actual presence. Would that work?


> > People are lazy and like myself don't want to sync pbuilder and
> > related stuff every time I want to upload something. Since my box is
> > rarely up to date, this can result in dependencies lagging
> > somewhat compared to official buildd. I generally don't check for any
> > build-depends problems anyway with pbuilder unless buildd chokes.
> 
> Goodness.

It's not goodness. It is reality that dependencies will *lag*
somewhere. Be it on dev box, or buildd themselves.

Build dependencies are not installable in pbuilder for days if not
longer for certain packages. I've also had number of times where my
build was ahead of buildd environment and then a packages has one set
of dependencies for buildd and another for my upload.


And seriously, you write "goodness" to lagging dependencies and
lack of pbuilder, but above you write "And thus allow people to upload
without ever building locally." I seriously think there are trust
issues. You (whoever made the policy) trust people to use pbuilder
all the time but you would NOT trust people to only upload packages
that build on their boxes. I, on the other hand, would trust people to
actually build packages and *test* them on their boxes *prior* to
upload.

Anyway, I raise this trust issue in another reply with some better
examples of what is trusted and what appears to be not trusted.

- Adam


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

Re: ReBuild-Depends?

[Adam Majer]

On Thu, Oct 29, 2009 at 06:33:12PM +0300, Dmitry E. Oboukhov wrote:
> This code works fine by libc wouldn't be rebuilt (new versions, or new
> gcc - this moment is ambiguous to me).
> Then this code begins segfaulting into this place.
> If we try to rebuild our package, it will begin to work fine again.

I doubt it is related to libc or gcc. Something is buggy with the
actual software. Try running valgrind and checking for out of bounds
memory accesses in the version that does not segfault.

- Adam


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

Re: Minimal kernel version raised to 2.6.27

[Adam Majer]

On Wed, Nov 11, 2009 at 07:56:16AM +0100, Bastian Blank wrote:
> On Tue, Nov 10, 2009 at 06:08:08PM +0100, Marco d'Itri wrote:
> > Due to changes in udev 147, squeeze will not support kernels earlier
> > than 2.6.27.
> 
> What are these changes?

Seems it is related to signalfd4 syscall.

- Adam


[1] - 
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=1da6c797fdbb94372c1a809acf1a0ca159b2d7b1

[2] - http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=udev/udevd.c


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

Re: Iceweasel and Firefox compatibility

[Adam Majer]

On Tue, Nov 10, 2009 at 09:57:22AM +0100, Mike Hommey wrote:
> I just decided I don't care anymore. So here is a deal to those reading
> this thread. Give me a UA string that:
> - Doesn't claim to be Firefox (i.e keep Iceweasel in it)
> - Is compatible with most crappy sites on earth[1] (i.e. Test it. A lot)
> 
> And I will change it before squeeze freeze.

It is not possible to come up with such a UA string.

Opera does allows per-site configuration of the UA string. Opera lies
a lot in name of compatibility. Anything else will definitely not work
on some of the borked sites out there. Might as well keep Iceweasel's
current UA string.

- Adam


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

Re: The horde of sloppy maintainers is a myth. Maybe not. Maybe yes.

[Adam Majer]

On Thu, Nov 12, 2009 at 12:45:36PM +0100, Cyril Brulebois wrote:
> Charles Plessy  (12/11/2009):
> Look at e.g. the history of non-buildability for Alastair McKinstry's
> packages. udunits[1,2] comes to mind. (Note I don't think I'm a
> carebear, but that I'm not that used to YELLING in bugreports. Until
> then.) hdf-eos4[3] or hdf-eos5[4] are nice, too. Happened with other
> packages, too.
> 
>  1. https://buildd.debian.org/build.cgi?pkg=udunits
>  2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545653
>  3. https://buildd.debian.org/build.cgi?pkg=hdf-eos4
>  4. https://buildd.debian.org/build.cgi?pkg=hdf-eos5

To me the *interesting* part is 

 *HOW* did the current policy of requiring binaries to accompany
  uploads address sloppiness with these uploads?

The obvious answer is it did not. On the contrary, it allows
questionably built packages into Sid potentially breaking other
package's dependencies. Consider,

  1. libfoofoo maintainer uploads with binary and new ABI for AMD64
  2. libfoofoo FTBFS
  3. ubberapp maintainer builds their app in pbuilder on AMD64 and
  uploads with high priority due to security fix
  4. ubberapp now depends on questionable binary on AMD64 and buildd
  binary on rest of architectures. Can't migrate to testing.

For source only upload, #2 would prevent #4 from occurring.


Another followup is how source-only uploads would affect quantity of
FTBFS? And if FTBFS would increase due to laziness of DD to actually
compile packages, would this result in buildd machines' queues to
increase so they are always behind?

My guess is trivial FTBFS would not increase significantly except
maybe for Arch:all.

I would rather have source-only uploads and have some sort of automated
script keep track of uploads and FTBFS. Use that as means of
monitoring quality of work of DDs. If a DD for the last 10 uploads has
6 FTBFS then maybe it would be something that could be addressed as
area of improvement or simply retiring from the project.


> Note that _you_ started asserting things, _you_ should be presenting
> facts to back it up. And if you really want a list of maintainers not

You've got to stop with the rage in your replies. :)

Cheers,
Adam


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

Re: Headsup: ncurses soname bump 5 to 6

[Adam Majer]

Steve Langasek wrote:

On Tue, Sep 16, 2008 at 09:21:44PM +0200, Daniel Baumann wrote:


There is no hurry, but please start using soname-independent
build-depends on ncurses as 'libncurses-dev | libncurses5-dev' in your
next uploads.


Does this mean it /can't/ be handled with binNMUs because you're changing
the -dev package name?


Daniel probably meant "it could be handled by binNMUs" provided people 
upload their package(s) with the new build-depends before the transition 
starts.


- Adam


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

Bug#509213: ITP: qtcreator -- IDE specifically designed for Qt

[Adam Majer]

Package: wnpp
Severity: wishlist
Owner: Adam Majer 

* Package name: qtcreator
  Version : 0.9.1-beta
  Upstream Author : Nokia
* URL : http://trolltech.com/developer/qt-creator
* License : GPL
  Programming Lang: C++
  Description : IDE specifically designed for Qt

Qt Creator is a lightweight development environment (IDE) designed to
make development with the Qt application framework faster and easier.
  * Tailored specifically to the needs of Qt developers creating
cross-platform applications
  * Focuses on features that boost developer productivity without
getting in their way
  * Helps new Qt developers get up and running faster
  * Open and extendable; integrates familiar tools and file formats



-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)



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

Bug#434583: ITP: tbb -- Thread Building Blocks is a parallelism library for C++

[Adam Majer]

Package: wnpp
Severity: wishlist
Owner: Adam Majer <[EMAIL PROTECTED]>

* Package name: tbb
  Version : 2.0~20070719
  Upstream Author : Intel Corporation
* URL : http://www.threadingbuildingblocks.org/
* License : GPL with runtime exception
  Programming Lang: C++
  Description : Thread Building Blocks is a parallelism library for C++
 
TBB is a library that helps you leverage multi-core processor
performance without having to be a threading expert. It represents a
higher-level, task-based parallelism that abstracts platform details
and threading mechanism for performance and scalability.
.
For more information see http://www.threadingbuildingblocks.org/




The runtime exception is to the GPL license is,,
   As a special exception, you may use this file as part of a free
   software
   library without restriction.  Specifically, if other files
   instantiate
   templates or use macros or inline functions from this file, or you
   compile
   this file and link it with other files to produce an executable,
   this
   file does not by itself cause the resulting executable to be
   covered by
   the GNU General Public License.  This exception does not however
   invalidate any other reasons why the executable file might be
   covered by
   the GNU General Public License.

http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (5, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-rc1 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


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

Bug#446316: ITP: ptop -- ptop is a utility that displays current state of PostgreSQL processes

[Adam Majer]

Package: wnpp
Severity: wishlist
Owner: Adam Majer <[EMAIL PROTECTED]>

* Package name: ptop
  Version : 3.6.1~b1
  Upstream Author : Mark Wong <[EMAIL PROTECTED]>
* URL : http://pgfoundry.org/projects/ptop/
* License : BSD License
  Programming Lang: C
  Description : ptop is a utility that displays current state of PostgreSQL 
processes

ptop is a utility that provides a display of top PostgreSQL processes
and other database statistics such as:
 - Current queries,
 - Query plans,
 - Locks,
 - User table statistics, and
 - User index statistics


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (5, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-1-k7 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#458386: Install scripts require dpkg (>= 1.10.24) for bzip2 compressed debs

[Adam Majer]

Package: general
Severity: normal

While attempting to upload a new package with bzip2 compressed dpkg, I
got a reject mail with,


Rejected: rails_2.0.1-1_all.deb: uses bzip2 compression, but doesn't
Pre-Depend on dpkg (>= 1.10.24)


This pre-depend is only needed for Sarge. Etch does not need this
check. Please remove this check.

- Adam


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (5, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Help needed: builds eating all memory

[Adam Majer]

On Sat, Oct 11, 2003 at 04:00:34PM +0200, Sam Hocevar wrote:
>My openvrml packages have been failing to build on arm [1], mips [2]
> and mipsel [3] for some time. From the build logs, it looks like g++ is
> eating all the memory and the OOM killer kills it.
> 
>What can I do? Ask the buildd admins to add more swap? I would be
> happy to cross-compile the packages (they don't require any arch-specific
> bootstrapping) but I don't have enough hard drive space to build a cross-
> compiler.

Whatabout removing the -O2 switch? It can save some compilation time and
memory for very large files..

How much RAM are we talking about here anyway? What is the memory usage
on your machine and on the machines in question?

- Adam

Re: Packaging sysfsutils: static library?

[Adam Majer]

On Sun, Oct 12, 2003 at 01:05:11AM +0200, Martin Pitt wrote:
> Hello everybody!
> 
> Today I read about the upcoming architecture for kernel device files
> [1]. devfs is already marked obsolete (what a pity, I really like
> it...) and will be replaced by an userspace daemon udev.

Me too, but I guess I'll have to see how udev looks. How does it look
like? Will it retain compatability with the devfs device names?

> Since this is stuff that will still change frequently and it is not
> used by real applications yet, I think it is sensible just to ship a
> static library and the two programs in a single package "sysfsutils"
> now. When the interface stabilizes and the library comes to real use,
> I would provide the full set of shared library, -dev and -runtime
> package.

You do not have to have a seperate -dev and -runtime package if the
library is small, especially if it is not used by many applications.

> Is it reasonable to provide just a static library? Policy 8.3 allows
> it in principle, but since I'm not very experienced at this, I would
> welcome any suggestions and your opinions.

Sure, but is it always nice to have a dynamic library if more than 
one program is going to be using the library.

- Adam

Apache fails to build in woody...

[Adam Majer]

Hi,

I can't seem to be able to build apache from source in woody:

--- configure: APACI and APXS ---

cp build-tree/apache-contrib-1.0.8/mod_macro/mod_macro.c 
build-tree/apache_1.3.26/src/modules/extra
cd build-tree/apache_1.3.26 && CFLAGS="-D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -O1" ./configure --target=apache --with-layout=Debian 
--enable-suexec --suexec-caller=www-data --suexec-docroot=/var/www 
--includedir=/usr/include/apache-1.3 
--suexec-logfile=/var/log/apache/suexec.log --without-confadjust 
--without-execstrip --enable-shared=max --enable-rule=SHARED_CHAIN 
--enable-module=most --enable-module=status --enable-module=auth_digest 
--enable-module=log_referer --enable-module=log_agent --enable-module=auth_db  
--activate-module=src/modules/extra/mod_macro.c
Configuring for Apache, Version 1.3.26
 + Warning: Your 'echo' command is slightly broken.
 + It interprets escape sequences per default. We already
 + tried 'echo -E' but had no real success. If errors occur
 + please set the SEO variable in 'configure' manually to
 + the required 'echo' options, i.e. those which force your
 + 'echo' to not interpret escape sequences per default.
 + using installation path layout: Debian (config.layout)
 + activated macro module (modules/extra/mod_macro.c)
Creating Makefile
Creating Configuration.apaci in src
 + enabling mod_so for DSO support
Syntax error --- The configuration file is used only to
define the list of included modules or to set Makefile in src
options or Configure rules, and I don't see that at all:
apache
no
default
yes
no
no
no
yes
no
default
no
default
default

<... bunch of empty lines here ...>

make: *** [configure-stamp] Error 1


Can anyone build apache in woody? The sources are from the security server.

Thanks,
Adam



signature.asc
Description: Digital signature

Re: possible mass bug filing: spamassassin 3

[Adam Majer]

Tollef Fog Heen wrote:

>* martin f krafft 
>
>| What do you think?
>
>API changed generally means you bump soname.  Why not for SA as well. 
>
>Also, SA3 is useless, as it eats about half a gig of RAM on my
>system.  Per child.
>
>  
>

After running for a little while,

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
   

 2024 adamm 15   0  176m  42m  36m S  2.0  4.2   0:37.11 mozilla-thunder


 2109 adamm 15   0 80764  28m  29m S  0.0  2.8   0:05.19 firefox-bin


 1271 root   5 -10  156m  24m 146m S  0.3  2.5   0:58.67 XFree86


 2925 root  25   0 25320  22m 4836 S  0.0  2.2   0:10.05 spamd  


 2929 root  25   0 25324  22m 4836 S  0.0  2.2   0:09.14 spamd  


 2926 root  24   0 25320  22m 4836 S  0.0  2.2   0:09.15 spamd  


 2927 root  24   0 25320  22m 4836 S  0.0  2.2   0:09.15 spamd  


 2928 root  24   0 25320  22m 4836 S  0.0  2.2   0:09.15 spamd  


 2924 root  25   0 24040  21m 4836 S  0.0  2.1   0:00.48 spamd  



I wouldn't say it uses half a gig of ram. Something else is going on..

- Adam

-- 
Building your applications one byte at a time
http://www.galacticasoftware.com

Re: possible mass bug filing: spamassassin 3

[Adam Majer]

martin f krafft wrote:

>also sprach Adam Majer <[EMAIL PROTECTED]> [2004.10.06.1934 +0200]:
>  
>
>>After running for a little while,
>>
>>
>[...]
>  
>
>>I wouldn't say it uses half a gig of ram. Something else is going
>>on..
>>
>>
>
>I had -m10 passed to spamd for 2.64. When I upgraded, I left that in
>place. I almost hosed a server that went up to load 30 immediately.
>It took me 40 minutes to get a shell, another 30 to halt postfix and
>unload SA.
>
>Now it's running at -m5 (the suggested value) and I have not had
>problems since. Of course, now I only get half the throughput, and
>my queue has not emptied for a whole day because SA is unable to
>keep up.
>
>  
>
Spamassassin 2.63 used less ram,

  PID USER PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
14615 spamd 16  15 23204  11M  4708 S N   0.0  2.3   0:24 spamd

so that would be about 40% of what spamassassin 3.0 seems to be using at
the start and about 1/4 of what 3.0 used in my little run below.

3.0 is also seems slower than 2.63 probably because new/better tests
were added..

I've also run spamassassin (spamassassin --mbox < mbox > obox), where
mbox is about 850 messages. It took spamassassin,

real2m45.994s
user2m34.211s
sys 0m1.949s

It also used a max of 40MB during the run.

This means that spamassassin 3.0 scans at a rate of about 5 message per
second on Athlon 2000+. Max thoughput for the day should be at about
400k messages, but probably <100k should be a better target.

Concurrency is not going to help you unless CPU is idle. In my case, -m
2 would use 100% CPU (not using razor).

- Adam

PS. 3.0 seems *much* better at detecting obfuscated spam. Where 2.63
gave an email 0.5, the new version gives it 7.3. Spam beware! :) On the
other hand, this is a type of spam arms race. Running spamassassin will
become more expensive as it improves.

-- 
Building your applications one byte at a time
http://www.galacticasoftware.com

Re: Smooth Debian Installer Experience

[Adam Majer]

Colin Watson wrote:

>On Sat, Oct 09, 2004 at 12:48:27AM +0200, Tilo Schwarz wrote:
>  
>
>>Just one remark: When I was asked to enter a package server I would have 
>>liked to enter my local package repository (with all the base stuff in 
>>it), but either I couldn't or I didn't see it. But, never mind ...
>>
>>
>
>Scroll up to the top of the country list and you'll see "enter
>information manually".
>  
>
Not to nitpick here, but shouldn't options like "None of the above" be
at the end of a list? Generally, the idea of picking something from a
list is to go though the list, and if not found, to select "Not on this
list" item. This means you start at the beginning of a list, and go
towards the end.

- Adam

-- 
Building your applications one byte at a time
http://www.galacticasoftware.com

Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter

[Adam Majer]

On Fri, Aug 30, 2002 at 04:55:46PM +0200, Robert Millan wrote:
> On Fri, Aug 30, 2002 at 10:31:23AM -0400, Joe Drew wrote:
> > On Fri, 2002-08-30 at 10:16, Robert Millan wrote:
> > > currently non-US is the only place where it can be without breaking law.
> > 
> > This is incorrect: mp3 patents exist in non-US places too, like Germany.
> 
> we definitely need an mp3 decoder in debian if we want to fight the
> patent oppression at all. i think we need another branch for that kind
> of problems.

lol, I doubt it would help. Just go to US patent office website and 
do a search on stuff like on title try "The Wheel". :) I know, it's getting
ridicules. What need to be done is for someone to sue the patent
office for stifling innovation and promoting monopolies. ie. something it
was originally created to fight.

> > > having mp3 players in non-free would still be illegal. mpg321 is free
> > > software that complies to DFSG and there's no reason to put it in
> > > non-free or non-free/non-US.
> > 
> > If fraunhofer say that you are allowed to distribute mp3 players for
> > free (but not for cost), then they must be put in non-free. And since
> > they have patents all around the world, they can't be put in non-us.
> 
> yes, but only non-free in states that impose patent restrictions. if we
> have such "non-patented" branch it would be free for users outside the circle.

I'm not sure, but an app A that incorporates algorithm BOB and BOB is "patented"
under a non-GPL license, then I don't think that A can be distributed as 
a GPL program.

Re: Bug#150411: Release-critical Bugreport for April 4, 2003

[Adam Majer]

On Fri, Apr 11, 2003 at 10:27:06AM +0100, Colin Watson wrote:
> On Fri, Apr 11, 2003 at 09:06:29AM +0200, Andreas Tille wrote:
> > On Fri, 4 Apr 2003, BugScan reporter wrote:
> > > Package: xshipwars-server (debian/main)
> > > Maintainer: Adam Majer <[EMAIL PROTECTED]>
> > >   150411 [P  ] xshipwars-server: POSIX shell incompatibilities
> > >   173966 [   ] xshipwars-server: won't uninstall unless the server is 
> > > running!
> > 
> > This package has is taged patch to one bug and in fact includes another
> > patch in the text of the other bug which is tagged pending.  Moreover
> > it contains an offer from Colin Watson to sponsor the package from
> > half a year ago.  I guess someone should hijack the package.

Yo, what's the dillio? At least *ask* me if I'm still here! :)

Both bugs are trivial and xshipwars wouldn't be going anywhere anyway
because lijsw has to get fixed (it is a C library compiled as
C++ library - for why look at the orig.tar.gz files).

If you want to hijac a package, look at some of the O: packages
that need to get picked up.

> Hold it for a bit, please. I've been talking to the maintainer privately
> for the last week. An upload is waiting until the new libjsw is
> accepted.

As he said :)

- Adam

Re: Bug#150411: Release-critical Bugreport for April 4, 2003

[Adam Majer]

On Mon, Apr 14, 2003 at 05:27:48PM -0600, Joel Baker wrote:
> [ I host the xshipwars upstream mailing lists... ]
> 
> On Fri, Apr 11, 2003 at 11:32:04AM -0500, Adam Majer wrote:
> > On Fri, Apr 11, 2003 at 10:27:06AM +0100, Colin Watson wrote:
> > > On Fri, Apr 11, 2003 at 09:06:29AM +0200, Andreas Tille wrote:
> > > > On Fri, 4 Apr 2003, BugScan reporter wrote:
> > > > > Package: xshipwars-server (debian/main)
> > > > > Maintainer: Adam Majer <[EMAIL PROTECTED]>
> > > > >   150411 [P  ] xshipwars-server: POSIX shell incompatibilities
> > > > >   173966 [   ] xshipwars-server: won't uninstall unless the 
> > > > > server is running!
> > > > 
> > > > This package has is taged patch to one bug and in fact includes another
> > > > patch in the text of the other bug which is tagged pending.  Moreover
> > > > it contains an offer from Colin Watson to sponsor the package from
> > > > half a year ago.  I guess someone should hijack the package.
> > 
> > Yo, what's the dillio? At least *ask* me if I'm still here! :)
> > 
> > Both bugs are trivial and xshipwars wouldn't be going anywhere anyway
> > because lijsw has to get fixed (it is a C library compiled as
> > C++ library - for why look at the orig.tar.gz files).
> > 
> > If you want to hijac a package, look at some of the O: packages
> > that need to get picked up.
> > 
> > > Hold it for a bit, please. I've been talking to the maintainer privately
> > > for the last week. An upload is waiting until the new libjsw is
> > > accepted.
> > 
> > As he said :)
> 
> You're a braver soul than I. I started a packaging attempt on it once (long
> ago), and... well... let's just say I know the insides of the code, and I
> have known the primary author since well before the project existed, and
> I will never, ever try to package it again as long as she's the primary
> author...
> 
> (In other words, I'm vouching to anyone who wonders that the code is enough
> to drive anyone seriously insane, and making it sane is no easy task.)
> -- 
> Joel Baker <[EMAIL PROTECTED]>


Lol. :) Well, the code is somewhat screwed up in places. For example

   *ptr++ = *(ptr + 1); 

I guess it could be more convoluted :)

But the real problem is not the code, it's the upstream. I tried telling
her the advantages of using something like automake/autoconf. But
that hit a brick wall since she doesn't understand it and, from what
I gather, does not want to learn to even use it (after I offered and
partially converted yiff, libjsw, etc... to using those tools!!)

I also wanted to provide a public and development CVS (heck, I could host it on 
my server)
so that the projects have some sort of version control, but, well, she didn't
want to learn any CVS (ie. the user side).

And let's not even start to talk about sonames :)

Plus you have .cpp files that are actually .c files etc :)

Anyway, the upstream is basically stagnant. I think that libjsw
and yiff and xshipwars will stay in sarge but I think they'll 
best get removed by sarge+1... We'll see if there are some good
alternatives..

The bugs are now in progress of getting sponsored, so they
will finally get fixed :)

- Adam

Re: plagiarism of reiserfs by Debian

[Adam Majer]

On Tue, Apr 22, 2003 at 09:58:08AM -0600, Ed Boraas wrote:
> Hello, all.
> 
> Ideally, I think, including the verbatim message in a separate file 
> ("SPONSORS"?) and including a reference to that file in mkreiserfs' 
> output should serve as an acceptable balance. I'm willing to reconsider 
> that position, however, if the authors and/or users disagree.

Repetitive, largely useless to the user messages like those should 
be removed and put in a file like SPONSORS or whatever. I would 
NOT use any program that is going to spew out poinless stuff
when I do not want to see it.

Fortunatelly, I use XFS and now I have no insentive to switch
to RaiserFS - I think the upstream needs to control his ego a bit
or not release the source under GPL. Having a one or two liner message
during startup of a command line utility is fine by me. Having 
5 pages of stuff is not fair to the user. Period. 

The job of a maintaier is to make the software as usable to a user
as possible. This includes removing excess repetitive messages.

- Adam

Re: plagiarism of reiserfs by Debian

[Adam Majer]

On Fri, Apr 25, 2003 at 04:44:58AM +0200, Bernd Eckenfels wrote:
> On Thu, Apr 24, 2003 at 08:59:42PM -0500, Adam Majer wrote:
> > Repetitive, largely useless to the user messages like those should 
> > be removed and put in a file like SPONSORS or whatever. I would 
> > NOT use any program that is going to spew out poinless stuff
> > when I do not want to see it.
> 
> one could think about a ~/.reiser-motd flag file which will make sure the
> message is displayed only once. But especially the boot time stuff might be
> too risky to implement somethign like this.

But people just DO NOT read these things! They just see "This program was
supported by... BLAH BLAH... BLAH..." :)

Putting in flags anywhere is not necessary because it should go
into file like SPONSORS in /usr/share/doc/. People that
are interrested can easily find it. People that do not care about
it, will not see it.

BTW, putting in these messages reminds me of those old DOS programs that
nagged everyone about seding $5 to the author...

- Adam

Re: libmysqlclient12 is GPL *not* LGPL

[Adam Majer]

On Fri, Apr 25, 2003 at 02:01:58PM +0200, Andreas Metzler wrote:
> Hello,
> I send this first here to doublecheck that I do not make a complete
> ass out of myself ;-)
> 
> You might not have noticed but libmysqlclient12 from MySQL 4 is
> licensed GPL, i.e. you have got problems when linking against non-GPL
> software at the same time. The LGPLed libmysqlclient10 and
> libmysqlclient10-dev from MySQL 3 have been resurrected by
> Steve Langasek.
>
> Afaict at least the following packages seem to need changes because
> they Build-Depends on either libmysqlclient-dev or libmysqlclient12-dev
> together with libssl-dev and produce a package that depends on
> libmysqlclient* and libssl*

I'm sure you alrady saw this, but

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=188723

So packages _have_to_ build-depend on libssl* if they build-depend on
libmysqlclient-dev since depends are _broken_ in libmysqlclient-dev!!

Isn't there are a way of making MySQL not use OpenSSL?

Anyway, this is preventing MySQL Control Center from enterring Debian :(

- Adam

Re: Screwed up fonts in _ALL_ Qt applications :(

[Adam Majer]

On Fri, May 16, 2003 at 01:33:12AM -0500, Chris Cheney wrote:
> On Sun, May 11, 2003 at 09:00:02PM -0700, Brian Nelson wrote:
> > Something related to #189750, perhaps?
> > 
> > -- 
> > Looks like excitement by repetition!
> 
> It is very unlikely that it is related to 189750, but it could be
> something related to how fontconfig chooses fonts. For example the
> medium font selection in Konsole ends getting a CJK font instead of a
> regular monospace one, which makes it look very wide.

It's not related - when the bug was fixed the bad font remained.
I really think that there should be _a_lot_ more weight placed on
the the type of font (ie. latin1/korean difference should have more 
weight than scalable/bitmap or bold/normal.

Re: Do not touch l10n files (was Re: DDTP issue)

[Adam Majer]

On Tue, May 13, 2003 at 01:31:59AM +0200, Denis Barbier wrote:
> 
> Unfortunately 0xa0 is the no-break space which is very common in
> French typography.  One could argue that Tollef was not aware of this
> fact, but the question is: why does he believe that he can change this
> localized file when he obviously does not master this language?

[snip]

> In short, do not modify PO files unless gettext reports some warnings.
> Only apply your changes to English text, and translators will take
> care of propagating these changes.

I completely agree with you. And frankly, we need more "english" -> English
translators. ;)

- Adam

Re: Warning: python-apt in testing broken, aptitude users DO NOT UPGRADE

[Adam Majer]

On Sun, May 18, 2003 at 10:01:31PM -0500, Taral wrote:
> Looks like the python2.2 stuff migrated into testing without noticing
> that it breaks python-apt. Anyone using python-apt (e.g. aptitude users)
> are advised not to upgrade.
> 
> Anyone know how exactly the testing scripts managed to miss this
> breakage?

I'm just guessing here (didn't check yet), but isn't it more likely that
people just didn't file a bug against python2.2?

- Adam

Re: thomas's trivia crusade

[Adam Majer]

On Sat, Dec 22, 2001 at 10:16:15PM +1100, Craig Sanders wrote:
> On Sat, Dec 22, 2001 at 11:17:34AM +0100, [EMAIL PROTECTED] wrote:
> > Craig [EMAIL PROTECTED]@Sat, 22 Dec 2001 03:50:08 +0100:
> > >  they are actually *REAL* bugs that affect the operation of the
> > >  package, not trivial items like spelling mistakes that affect
> > >  nothing.
> >
> > And because developer x does not fix his bugs, you think you shouldn't
> > fix your bugs either? Think about your developer karma[0] man! ;-)
> 
> no, that's not what i said.
> 
> i said that there are real bugs that are actually worth spending time
> on...as opposed to non-bugs like whinges about the words "zonefile" and
> "usenet".


Let's end this crap about spelling shit. I don't really care who is right about 
proper spelling for these 
words. First, case shouldn't be a problem for searching - what if the word is 
at the beginning of a sentence???

And I use 'zonefile' and 'zone file' interchangeably. Heck, I would search for 
'zonefile' first.

File bug reports and if they don't get all fixed for stuff like "zonefile" then 
so be it. So plz, end this
_CRAP_ about spelling [this goes to ALL involved] and let us have a Marry 
Christmas :)


- Adam

Re: Sparc buildd a cross-compiler?

[Adam Majer]

On Sat, Dec 22, 2001 at 12:17:51PM -0500, Ben Collins wrote:
> On Sat, Dec 22, 2001 at 05:19:27PM +0100, Mikael Hedin wrote:
> > 
> > Hi,
> > 
> > I noticed gsmlib has failed on sparc for a long time.  The last log,
> > http://buildd.debian.org/fetch.php?&pkg=gsmlib&ver=1.7-1&arch=sparc&stamp=1006071760&file=log&as=raw,
> >  
> > says in the end that g++-3.0 is a cross compiler:
> > 
> > checking whether the C++ compiler (g++-3.0 -Wall -D_REENTRANT -O2 ) 
> > works... yes
> > checking whether the C++ compiler (g++-3.0 -Wall -D_REENTRANT -O2 ) is a 
> > cross-compiler... yes
> > checking whether we are using GNU C++... yes
> > checking whether g++-3.0 accepts -g... yes
> > configure: error: can not run test program while cross compiling
> > make: *** [configure-stamp] Error 1
> 
> Your package better use gcc, not gcc-3.0. Using anything other than the
> default supported compiler gets you a bug report.

Some packages will not build with pre3 version of GNU C/C++ compiler. In my 
case I get an internal compiler 
error.


- Adam

Re: Sparc buildd a cross-compiler?

[Adam Majer]

On Sat, Dec 22, 2001 at 02:07:41PM -0500, Ben Collins wrote:
> On Sat, Dec 22, 2001 at 06:54:10PM +, Philip Blundell wrote:
> > G++ 2.95 is pretty broken in its own right.  Just because it won't compile
> > something doesn't necessarily mean that the source is at fault.  I wouldn't 
> > regard it as unreasonable for C++ programs to require 3.0 these days.
> 
> I don't think it is unreasonable in Debian to require that programs work
> with the default toolset available for the arch. Most of the archs do
> not use gcc-3.0 as the default. Keeping one toolchain in shape to
> compile the entire dist is enough work without having to require archs
> to maintain two stable toolchains.
> 
> That said, there are two issues:
> 
> 1) Currently on archs that use gcc-2.95 as the default, using gcc-3.0
> and especially g++-3.0 is not supported by libc6. The backward
> compatibility is not what it should be, and wont be until glibc 2.2.5.
> So using it now only means you potentially leave your app open to
> breakage later on.

Some programs will NOT compile with pre-3.0 gcc/g++. Take the jscalibrator [I'm 
just updating it]. It will not 
compile unless there are major changes done in the source and sorry, but I 
don't know where to start with this 
compiler problem:

jcdraw.c: In function `JCDrawAxisesRepresentative':
jcdraw.c:339: Internal compiler error:
jcdraw.c:339: Unable to generate reloads for:
(insn 805 803 808 (parallel[ 
(set (reg/v:SI 6 %ebp)
(fix:SI (fix:SF (reg/v:SF 33
(clobber (mem:HI (plus:SI (reg:SI 6 %ebp)
(const_int -10 [0xfff6])) 0))
(clobber (mem:HI (plus:SI (reg:SI 6 %ebp)
(const_int -12 [0xfff4])) 0))
(clobber (mem:SI (plus:SI (reg:SI 6 %ebp)
(const_int -8 [0xfff8])) 0))
(clobber (scratch:HI))
] ) 145 {fix_truncsfsi2+1} (insn_list 803 (nil))
(expr_list:REG_DEAD (reg/v:SF 33)
(expr_list:REG_UNUSED (scratch:HI)
(nil
make: *** [jcdraw.o] Error 1


If you have a suggestion of what is wrong, please, tell me and I'll make 
jscalibrator work with 2.95 :) Until 
then or until gcc >=3 gets into arch, some packages will simply not compile. 
IMHO, we should get the 3.x series 
of compiler into arch (in sid) sometime in the next 6 mo or so [after woody 
gets to stable].

- Adam

Re: package lists for older machines

[Adam Majer]

On Sat, Dec 22, 2001 at 06:57:54PM +0100, Marc Haber wrote:
> On Tue, 18 Dec 2001 21:15:58 +0100, Erich Schubert <[EMAIL PROTECTED]>
> wrote:
> >A P166 should be a great mp3 player, but gnome probably is overkill...
> >So you'll need another Packages.gz for mp3-players, another for servers
> >(which do not need gnome ;) usw.
> 
> So every package should have a control file stating its CPU
> requirements, memory requirements and what ever else comes to mind,
> and a tool should be able to filter Packages.gz according to these
> requirements. "Give me all packages that will run satisfactorily on my
> P166 with 32 MB".

How would the maintainer know that? Or upstream? And it might get changed in 
different versions. IMHO, people
should know what their computer can run. Generally a package not req. X will 
run better than that that req. X. 
Or a smaller package will run faster than a larger counter part In most 
cases it's not too difficult to
determine from descriptions.

> Of course, dpkg should be able to pull in the full database if the
> local admin desires to try running a program that doesn't fit the
> local machine according to the maintainer's opinion.

Fits in my 20MB :) + you should always have swap space.

> Or dpkg should move away from the flat text file approach and store
> some pre-compiled database somewhere. I believe this is being prepared
> for a few years now.

Or it can process the Package file in chunks so only use 1MB or so if free 
indicates small amounts of ram - 
<64MB? And run nice by def. would be nice too :)

-- Adam

Re: from potato to woody without a free internet connection

[Adam Majer]

On Fri, Dec 28, 2001 at 09:58:34PM +0100, Tom Jongsma wrote:
> Hello,
> 
> I'm running debian potato right now. I want to upgrade it to Debian Woody, 
> but I don't have a free internet connection.
> Can I update my potato by burning a cd on school. And Install it on my 
> machine at home? 
> I can't find cd-images (iso's) of debian woody.
> Aren't there cd-images of debian woody?

I'm not sure how official these are but there are some at:

http://www.planetmirror.com/pub/debian-cd/woody/i386/  [i386 only]

or for better bet go to

http://cdimage.debian.org/

then at the bottom there is a link to testing site. You can DL 9 CDs from the 
unofficial distro (woody)... from varoius sites.


- Adam

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Adam Majer]

On Sat, Dec 29, 2001 at 11:31:37AM +0100, Lenart Janos wrote:
> [Please Cc: to me! (ETOOHIGHVOLUME)]
> 
> As you might already have noticed Debian begun to bloat - so many
> unneeded, unused, unmaintained(!) packages.
> My opinion is that one DD alone couldn't upload NEW package, but he
> needs 2 proponent DD who are willing to "give his signature for it".
> Just to make it a little more complicated a minimum of 50 word long
> justification needed from all the 3 guys (e.g. two proponent DD and the
> future maintainer).

This doesn't sound too bad to me, _but_ a better report might be to set up some 
sort of automatic system that 
sends out email to all maintainers at 1 month intervals [or something like 
that]. If someone doesn't respond to 2 
or 3, then they are marked inactive and someone, preferable a human, verifies 
that the maintainer is not active 
anymore and orphans all of his/her packages... This would eliminate the 
unmaintained problem...

As for unused packages, it is a very subjective thing :) Something like iraf 
might now be used by many but it is
still needed by some.. Removing stuff like this turns Debian into RedHat - no 
one wants that.

Unneeded packages might still be used but then it is up to the maintaner to 
orphan them and if they are trully 
unneeded then they would not be adopted.

None of the above thing change the way that packages are maintaned - easier to 
implement. It would also catch the 
perm. AWOL maintainers. 


Any opinions??

- Adam


pgp7xHmPN6esm.pgp
Description: PGP signature

Re: Preparing a Proposal: 3 DD needed for every NEW package

[Adam Majer]

On Sun, Dec 30, 2001 at 01:44:38PM +0200, Juha J?ykk? wrote:
> > This doesn't sound too bad to me, _but_ a better report might be to
> > set up some sort of automatic system that sends out email to all
> > maintainers at 1 month intervals [or something like that]. If
> > someone doesn't respond to 2 or 3, then they are marked inactive and
> > someone, preferable a human, verifies that the maintainer is not
> > active anymore and orphans all of his/her packages... This would
> > eliminate the unmaintained problem...
> 
>   This could be nice... I might even volunteer for setting up
> something like that - given the authority, of course: orphaning other
> people's packages must be done responsibly...
>   This email that would be sent would be bug-list (or a subset
> thereof), right? A simple "Are you alive?" Would be quite annoying...
> Of course, a bug-list once a month would be annoying to active
> developers, too. Would it be possible to exclude from getting the email
> those maintainers who have uploaded a new version during the last,
> say, 3 months? This, of course, would still unnecessarily burden
> maintainers of packages which are more or less dead upstream and do
> not have any (important) bugs... We do not want to annoy maintainers,
> either... Of course, skipping maintainers of packages with no important
> bugs could help, too. This would be easy to implement, too.

This might actually work :)

A script that checks:
  * not uploaded anything in last 3 months?
  * not bug free? I would say any bugs here that are not tagged and less
than important should be included as well.
  * not uploaded anything in last year?

These should be traversed in that order, like a C AND statement so "bug
free" packages still get a reminder at least once a year -- manytimes
these might be not very used packages so not too many people complain.

Question about cdrecord and -audio

[Adam Majer]

Hi all,

I'm hopping that someone has some experience with audio CD recording and 
can help me a bit. I can record data CDs without any problems but if I 
try the audio option I get the following output


mira:/tmp# cdrecord -dev=0,0 -dummy -audio -pad t.iso
Cdrecord 1.10 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling
scsidev: '0,0'
scsibus: 0 target: 0 lun: 0
Linux sg driver version: 3.1.22
Using libscg version 'schily-0.5'
Device type: Removable CD-ROM
Version: 0
Response Format: 1
Vendor_info: 'LG  '
Identifikation : 'CD-RW CED-8120B '
Revision   : '1.02'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Driver flags   : SWABAUDIO
Starting to write CD/DVD at speed 4 in dummy mode for single session.
Last chance to quit, starting dummy write in 0 seconds. Operation 
starts.
cdrecord: Input/output error. write_g1: scsi sendcmd: no error
CDB:  2A 00 00 00 00 00 00 00 1B 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 64 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x64 Qual 0x00 (illegal mode for this track) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.002s timeout 40s
write track data: error after 0 bytes
Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00


I am not familiar enough with the CDR protocols to know what these 
things mean... Is this the problem with cdrecord or my drive?


Thanks for any help in advance,
Adam Majer


pgpbU7PIFqIVI.pgp
Description: PGP signature

Re: find eating all memory

[Adam Majer]

On Wed, Jan 02, 2002 at 06:45:53PM -0600, Bryan Andersen wrote:
> Andreas Rottmann wrote:
> > 
> > Michael De Nil <[EMAIL PROTECTED]> writes:
> > 
> > > Hi
> > >
> > > on a simple 'find /var -name sendmail* -print' command, the find-process
> > > eats all my memory (128 Meg RAM)
> > > when there is no memory left, the process gets killed.
> > >
> > > I work with debian woody with recent update, reiserfs, 128 meg RAM & 256
> > > meg SWAP on my P3 733 system.
> 
> Check the file system for symbolic link loops.

But these occur quite often.. especially with Nautilus - the Desktop directory 
has a link back to home. IMHO, find should 
be able to check for those loops.

- Adam

Re: Some thoughts about problems within Debian

[Adam Majer]

On Fri, Jan 04, 2002 at 03:22:09AM +0200, Fabian Fagerholm wrote:
> On Fri, 2002-01-04 at 02:23, Gustavo Noronha Silva wrote:
> > smooth introduction? you never heard of policy, maint-guide, developers'
> > reference, web pages, etc, have you?
> 
> Many operating systems have accompanying "certification" courses. These
> serve the need of gathering a knowledgeable user base to run the systems
> (MCSE, Sun cert, Cisco cert and so on). Why not try something similar,
> but less formal and on-line, in debian?

IMHO, that comes from experience and not memorizing some manuals. IMHO, these 
certs are useless pieces of paper. You 
learn things by fixing bugs and reading how others fixed bugs..

> As for the web pages, there is room for improvement. You don't need to
> comment on this; I know, I shouldn't complain and should do something
> about it. I'll try to do that.

IMHO, there is a _huge_ amount of servers that are not connected from main 
page... As of a week ago I could not find 
any links to qa.d.o, nm.d.o, buildd.d.o, etc It would be nice to have them 
at d.o/devel

> Agreed to 99%. But I maintain that target audience is of importance for
> coordination. There's a big difference in making, say, an email server
> compared to a desktop system. The former may assume a certain level of
> confidence in mail systems and computer systems in general - it's ok to
> have debconf ask some complicated questions, or requiring the sysadmin
> to edit configuration files. The latter would require quite a different
> approach, and could not make the same assumptions about the user's
> knowledge level.
> It may be possible to make a one-size-fits-all system which can fulfill
> the requirements of both the above examples, but we are already seeing
> some specialization occur, for example with the debian multimedia
> distribution. So target audience is important: how do you define "good
> documentation" and "good packages" if you don't know who is going to
> read the docs, and install the packages? There's more to it than having
> no spelling errors and as few bugs as possible.

IMHO, the questions asked by installation scripts are very clear.. For even a 
novice admin that is... After all, 
isn't admins or admin-wanna-bees what are installing a new system anyway? IMHO, 
I don't think that there is anything 
too cryptic being asked for desktop installation...

CHECK BEFORE YOU RETITLE Re: Processed: Retitling...

[Adam Majer]

Hey, buddy!! I ITA those packages a while back - I'll be uploading them in the 
next day!!! PLEASE CHECK THE O LIST 
__BEFORE__ YOU RETITLE A BUG!

- Adam


On Fri, Jan 04, 2002 at 03:03:14PM -0600, Debian Bug Tracking System wrote:
> Processing commands for [EMAIL PROTECTED]:
> 
> > retitle 123477 ITA: gtml -- An HTML pre-processor
> Bug#123477: ITA: gtml
> Changed Bug title.
> 
> > retitle 123480 ITA: yiff -- A network based and multi client connection 
> > system
> Bug#123480: ITA: Yiff
> Changed Bug title.
> 
> > retitle 123491 ITA: libhoard -- Fast memory allocation library
> Bug#123491: ITA: libhoard
> Changed Bug title.
> 
> > retitle 123508 ITA: xshipwars -- Dynamic space-oriented gaming system
> Bug#123508: ITA: xshipwars: Dynamic space-oriented gamming system
> Changed Bug title.
> 
> > retitle 123509 ITA: xshipwars-images-st -- Image Collection for XShipWars
> Bug#123509: ITA: xshipwars-images-st: Image Collection for XShipWars
> Changed Bug title.
> 
> > retitle 125886 ITA: xshipwars-sounds-st -- Sound Collection for XShipWars
> Bug#125886: ITA: xshipwars-sounds-st
> Changed Bug title.
> 
> > retitle 126198 O: saml -- Simple Algebraic Math Library
> Bug#126198: ITA: saml
> Changed Bug title.
> 

> Please contact me if you need assistance.
> 
> Debian bug tracking system administrator
> (administrator, Debian Bugs database)

Re: Some thoughts about problems within Debian

[Adam Majer]

On Sat, Jan 05, 2002 at 04:43:10PM +0100, Tollef Fog Heen wrote:
> * Adam Majer 
> | clear.. For even a novice admin that is... After all, isn't admins
> | or admin-wanna-bees what are installing a new system anyway? IMHO, I
> | don't think that there is anything too cryptic being asked for
> | desktop installation...
> 
> Then you are _very_ wrong.  There are too many and too complicated
> questions asked for a ?normal user?, whatever that is.  You have to be
> interested and/or have somebody help you install Debian, else you will
> give up halfway.

Well, the defaults are usually the correct choice anyway.. Some questions for 
setting up X might be a bit criptic but 
that is X and it would be very difficult to get them more "user friendly".

- Adam

Re: CHECK BEFORE YOU RETITLE Re: Processed: Retitling...

[Adam Majer]

> Hi Adam,
> 
> it seems you misunderstood what Uwe was doing: He did only add the package
> descriptions to the WNPP bugs, IOW he changed e.g.
>   ITA: gtml
> to
>   ITA: gtml -- An HTML pre-processor
> or
>   O: wmf
> to
>   O: wmf -- Web Mail Folder
> 
> 
> These changes are visible e.g. in the wookly work-needing packages report
> or at the WNPP pages at [1]. Uwe never intended to adopt any of these
> packages.

Hi,

He did change some ITA to O - I have no idea why... IMHO, the 
difference b/w

 ITA: gtml

and

 ITA: gtml -- An HTML pre-processor

is trivial.. There should be no reason to do that especially 
that the package is ITA: for a few days... And generally adding 
a comment to something like:

"Just changing the title to be more readable - not attempting to 
adopt."

would suffice.

IMHO, retitling to ITA: without explanation is seen as an attemp 
to adopt a package..

Thanks,
Adam Majer

Re: maintainer for cervisia is MIA

[Adam Majer]

Try sending email to QA or something. Maybe they should orphan the package
owned by that maintainer.

- Adam

On Sun, Jan 06, 2002 at 01:34:53AM +0100, Ulrich Eckhardt wrote:
> I mailed the maintainer of the above package on the eleventh of december and 
> haven't got a reply yet. All the bugs of the package are pretty old, a new 
> version of the proggy is also available upstream, current version is > a year 
> old.
> 
> what should I do/can be done?
> Uli

Re: packaging spambouncer - cronjob updates in /usr???

[Adam Majer]

On Sun, Jan 06, 2002 at 05:31:28PM +0100, martin f krafft wrote:
> if i package spambouncer so that a configurable cronjob obtains updates
> on the anti-spam rules and databases from the spambouncer website, then
> the files can't remain in /usr, right?
> 
> the primary candidate for installation of spambouncer is
> /usr/share/spambouncer, but /usr/lib/spambouncer might be better. in any
> case, since /usr should be ro-mountable, these files should really be
> sitting in /var/lib, right? that would mean that the entire "program"
> sits in /var. is this acceptable?

The changing things go in /var/lib/spambouncer or something... If there 
are executables, these should go into /usr/bin or /usr/sbin or something.

- Adam

Re: [wish] buildd.debian.org that shows success/failure

[Adam Majer]

On Wed, Jan 09, 2002 at 12:33:09AM +0100, Stefano Zacchiroli wrote:
> An useful improvement in buildd.debian.org is show in a different color
> or with some graphic flag the builds that results in a failure.

Different color.. something like keep it black for successful build but 
mark it bold and red if it fails.. So at least bold would show up in lynx
if someone is still using it.

No pictures, please...


Thanks,
Adam