Re: Custom Debian package installation
On Mon, Apr 07, 2008 at 07:43:34AM +1000, David Schulberg wrote:
> I have a Debian package which starts a service set up by having
> ‘dh_installinit’ in my rules file.
>
> I want the service to start every time my computer boots up.
>
> Does it also have to fire up straight after I install the package?
>
> I have a configuration file that is part of my package which needs
> to be customised before I run the service that is installed by
> the package so I don’t want to run the service until I have done
> that.
The way this is usually tackled is to either have the initscript
refuse to start the service if not yet configured (but still exit
with an okay return value so package installation succeeds), or ship
a file in /etc/default/ sourced by the initscript and containing a
switch variable to make the initscript's start function a no-op
(until edited to turn it on).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Custom Debian package installation
On Wed, Apr 09, 2008 at 09:35:53PM +1000, David Schulberg wrote:
> So how can I actually check in my initscript that it is running
> during the installation process so I can skip the start of my
> service at that time?
You wouldn't. You'd add some intelligence to your initscript to
detect that the service hasn't been appropriately configured yet
(such as looking for a particular line in the config that would
always exist but always be changed from its default value), or by
having the initscript source a file your package provides in the
/etc/default directory which has an autostart=0 line (or similar)
and then use that variable in a conditional statement in the start
function of your initscript. There are many official packages in
Debian whose initscripts either won't automatically start a daemon
until it is configured, or won't start a daemon until you edit
/etc/default/something and reset a variable from 0 to 1. Finding
examples of these is left as an exercise for the reader (hint, look
in /etc/default on any Debian machine).
> At the moment my postinst file looks like this:
As it should. More importantly, what does your initscript look like?
(Also, please don't Cc me--I read the list.)
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Default admin password for a webapp
On Wed, Apr 09, 2008 at 04:54:38PM +0200, Xavier Luthi wrote:
> OK. Now let's suppose the password has not been set during the
> package configuration because debconf level was too high. The
> webapp won't allow any authentication becasue the password is not
> set. How to ask for a password?
[...]
People doing new package installs under these conditions are
expected to know where to find and how to read documentation. A
clear message in README.Debian describing how to generate the
password hash, what file/database table to put it in, and whether
any running services need to be (re)started should be more than
sufficient, I would think.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help with arch-specific bug in mapnik package
On Sat, Jun 07, 2008 at 02:12:12PM +0100, Dominic Hargreaves wrote:
[...]
> I'm not quite sure where to go with this one; not least because I
> don't have a way to reproduce the problem
[...]
I have a Hewlett Packard Model 712/60 workstation running sid, to
which I could give your RSA key login access. Unfortunately, it only
boasts a PA-RISC PA7100LC (PCX-L) 60MHz CPU, 32MB RAM and a 1GB SCSI
disk for / (I use NFS for /home). As already suggested, you'd
probably have more luck soliciting both machine access and
arch-specific expertise on the debian-hppa list, but I'm happy to
help any way I can.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
On Sun, Jun 22, 2008 at 05:41:11PM +0200, Olivier Berger wrote:
> Is there any use in adding your fingerprint to the signature ? ... It
> seems misleading at least, if users think they can trust that... and
> without the public key, it's useless anyway.
It's assumed that your public key can be commonly found on public
keyservers or by fingering your address. Putting your key
fingerprint in your .sig is *obviously* not equivalent to
cryptographically signing a particular message, but it does help
others identify that they've looked up the correct key for you if
they want to encrypt a response to you. It's only potentially
misleading if someone doesn't understand PKI in the first place, but
then what's the point of avoiding misleading someone about something
they don't know how to use in the first place? I don't know if the
extra 40 characters make my .sig obscenely larger, but if they did I
might shorten it to a key ID instead.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] : gpg fingerprint in mail's signature ? - Was: Re: RFS: gtkwhiteboard (now dfsg compatible)
On Sun, Jun 22, 2008 at 11:59:53PM +0200, Cyril Brulebois wrote:
> Even shorter: Sign your mails.
While I won't debate the relative merits, it's definitely not
shorter. According to wc -c your attached PGP signature is 197
characters long.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net SSL certificate under Ubuntu?
On Sat, Jul 26, 2008 at 01:00:57AM +0200, Cyril Brulebois wrote:
[...]
> If you ever reach the actual certificate, you should see the
> issuer is CA Cert, so you should be able to find a way to install
> it.
[...]
On Debian (and thus presumably Ubuntu as well), the public half of
CAcert's Class 1 PKI Key is shipped in the ca-certificates package
as:
/usr/share/ca-certificates/cacert.org/root.crt
Assuming you trust their certificate signing, add this as a trusted
CA for your browser (the process for doing this varies from one
browser to another).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Becoming a new contributor
On Wed, Aug 27, 2008 at 03:26:57PM -0500, [EMAIL PROTECTED] wrote:
[...]
> The program is a slideshow-type photo viewer. More specifically,
> it is meant give this functionality on older systems not running
> Gnome or KDE (like mine). It is quite simple, has no extra
> features such as zooming, and so far only supports the JPEG
> format. It is all original work, so I am putting it in the public
> domain. It is written in C.
[...]
Out of curiosity, what benefits does it provide over, say, using
xview from the xloadimage package? Smaller binary or resident memory
size? Requires less processing power? Easier to use?
xview -global -delay 2 /usr/share/pixmaps/*
"Can view png, jpeg, gif, tiff, niff, sunraster, fbm, cmuraster,
pbm, faces, rle, xwd, vff, mcidas, vicar, pcx, gem, macpaint, xpm
and xbm files. Can view images, put them on the root window, or dump
them. Does a variety of processing, including: clipping, dithering,
depth reduction, zoom, brightening/darkening and merging."
I've seen a rash of people reinventing wheels they don't realize
have existed since long before modern desktop environments, window
managers and, in this case, even the Linux kernel:
http://packages.debian.org/changelogs/pool/main/x/xloadimage/xloadimage_4.1-16/xloadimage.copyright
I'd just like to make sure this isn't the case here! ;)
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: get-you
On Fri, Aug 29, 2008 at 09:18:29AM +1000, Ben Finney wrote:
> We already have the package 'clive' for the same purpose.
And also the youtube-dl package as well.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy, apt-cacher & approx
On Mon, Sep 22, 2008 at 01:14:42PM +0800, Thomas Goirand wrote:
> We've been using apt-proxy for about a year, and then found it quite
> buggy. So we moved to using apt-cacher. Now we have loads of problems
> with apt-cacher as well (like currently, a recurring tzdata size
> mismatch error). I was wondering if approx is any better than the other
> two. Did any of you try?
I switched from apt-proxy to apt-cacher-ng on Sid at home a few
months ago and it's been great. I am, unfortunately, not having the
best of luck backporting it to Etch for work (sunk a couple hours
into it Friday afternoon before heading home, but haven't picked it
back up again yet this morning). It seems to compile and run fine on
Etch, but it doesn't behave as advertised (503 errors and fails to
download/cache any requested files). I may just cut my losses and
run it on a Lenny machine instead.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making .deb packages
On Thu, Aug 25, 2005 at 06:06:10PM -0400, jdgamble wrote:
> I'm not sure if this is the right group to post to, but I am trying to
> learn how to make deb packages and I seem to go around in circles
> confusing myself.
[...]
It is not. The debian-mentors list is devoted to this particular
topic, so I have Cc'd it and set Mail-Followup-To accordingly.
> I am new to this whole thing of creating deb packages. I am trying to
> make a deb file from the source of http://gotmail.sf.net so that they can
> post it with their sf project files.
[...]
The gotmail application has already been packaged for Debian for
years, is presently maintained by Paul Cannon and can be downloaded
using apt-get, from official mirrors or the packages page:
http://packages.debian.org/unstable/source/gotmail
I would discuss your packaging efforts for the upstream maintainers
with Paul, as it might make sense to simply mirror versions already
available in Debian (or not even bother, since Debian users will
just get it from the official mirrors anyway).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building rpms on debian system?
On Thu, Apr 20, 2006 at 03:32:14PM -0400, Kris Deugau wrote:
> [This is probably the wrong list for this.]
>
> Ek Zindagoi wrote:
> > I would like to build rpms on a debian system for use on a redhat
> >system. Can I do that on a debian system ?
>
> In short, no; system libraries on a RedHat system likely have different
> versions (and soversions), as well as a few different filesystem paths.
> Libraries *will* have different names, except in a few very rare
> cases. (Worse, all Debian libraries have package names "lib";
> very few RH libs do unless the upstream name is libsomething.)
[...]
I'm not sure I've seen what seems to me to be the obvious solution
come through in a reply yet, but why not just create a custom chroot
for your target distribution (be it RHEL 4 or SUSE 9 or whatever)
and build in there? Do it a la pbuilder and just keep a tarfile of
the clean system archived so you can have several without taking up
much space, and upgrade them periodically as needed. Your only
limitation is that you're stuck in the chroot using whatever kernel
you've booted for Debian, but if that becomes an issue, UML to the
rescue (in some ways easier to manage than chroots, in my opinion).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: weather-util - command-line tool to obtain weather conditions and forecasts
On Mon, Apr 24, 2006 at 09:19:45PM -0700, Russ Allbery wrote:
[...]
> Looks good to me at this point. I've gone ahead and uploaded it. You
> should shortly get the notification that it's waiting in NEW.
[...]
Got it--thanks! I'll keep an eye on the new queue and see if/when it
gets into sid.
> Does using the command line switch work when there isn't an entry in the
> database? I wasn't having any luck with just weather --id=KPAO, but I may
> have been missing something. And indeed, it seems to be working now.
> Must have just been pilot error.
Yeah, the aliases defined in your weatherrc are just conveniences to
keep from typing a bunch of command-line switches and to group
values together into a more memorable name. Nothing magic about
them. I opted to provide a global set that pre-defines a lot of
airport abbreviations as an additional nicety, and hope to expand
that as time goes on. If it gets unwieldy, I may shift the presets
to /usr/share/weather/aliases.gz or something and let /etc/weatherrc
be more for the admins to centrally override what they want without
having to edit a huge list of defaults.
> Thank you for writing it! This is something I'll probably use regularly.
> It's nice and simple and useful and doesn't require subjecting myself to
> piles of advertising on the web.
Necessity is the mother of invention. I was honestly shocked that I
couldn't find a tool capable of exactly this already in Debian, so
now hopefully nobody else has to be similarly shocked. My only
regret is that the (completely unrelated) "weather" package will be
in oldstable/non-free until etch+1, or I would have simply called my
package that.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: help with gmail
On Thu, Jun 08, 2006 at 08:45:03AM -0600, Joseph Smidt wrote:
> I received help with the depends scripts earlier but now I have a
> new problem. ${python: depends} is returning a dependency for >
> python 2.3 and << python 2.4. But the package requires python 2.4
> to work. Does anybody know how I can fix this? My packages are
> at josephsmidt.googlepages.com/debianpackages.
[please wrap your messages at 80 columns or less]
Depending on python isn't going to work for you since the default
python in sid is still python2.3:
[EMAIL PROTECTED]:~$ apt-cache show python|grep ^Depends:
Depends: python2.3 (>= 2.3.5-1)
I recommend reading the Debian Python Policy for a detailed
explanation of the problem you're encountering and possible
solutions:
http://www.debian.org/doc/packaging-manuals/python-policy/
Hope that helps!
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to compile source after I apt-get source it ?
On Fri, Jul 07, 2006 at 11:23:31PM +0300, Maxim Vexler wrote:
[...]
> Doing a simple ./configure gets me this :
[...]
The resulting unpacked Debian source package comes with a makefile
at ./debian/rules for configuring, compiling and making the
resulting Debian binary packages.
> So the questions are :
> a. How do I know what packages does tilda depends on to compile on my
> system ?
> b. Is there a debian utility that would go and get those packages for me ?
[...]
With root privs (su, sudo, whatever):
apt-get build-dep tilda
This will calculate and install all build dependencies for the tilda
source package. For compiling, I recommend debuild from the
devscripts package (you'll probably want to install fakeroot as
well). In the unpacked source directory, as a normal user you can do
something like:
debuild -b -uc -us --rootcmd=fakeroot
...and the resulting packages should appear in ../ when it's done. I
highly recommend reading appendix A of the Debian Developer's
reference:
http://www.debian.org/doc/developers-reference/ap-tools.en.html
Hope that helps!
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian: user-request-daemon (it could solve some problems)
On Fri, Feb 16, 2007 at 08:10:34AM +, Anton Piatek wrote:
> I have a feeling you have reinvented the wheel. Sudo can be used without
> a password and can be set on a per-user, per-application basis i.e. give
> user X permission to run Y with/without a password.
Even more flexible, sudo can be configured to use alternate means of
authentication, such as OTP, PKI or a ticket authority, often being
more secure options than reusable passwords when forced to admin a
system via a connection from some untrusted client machine. Also,
while I'm not sure I'd recommend it, sudo's rules (the sudoers file)
can be served to a network of machines from some central authority
such as an NFS export, YP/NIS+ or an LDAP backend. Not to mention,
the design and implementation of sudo has 27 years of historical
review and code audits from which to draw its assurance of security.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian: user-request-daemon (it could solve some problems)
On Tue, Feb 27, 2007 at 04:17:10AM +0100, Curt Manucredo wrote:
> i could never imagine that it is possible to call a command and then
> have root rights for it, without authentificating on the system with a
> password. so i thought a daemon running as root might solve that problem
> (which i thought it does exist) ;-). but since today i can not imagine
> how sudo is doing that - it might be very difficult to explain since i
> couldn't find an explantion on the net.
> so, how is sudo doing this auth-job, even with no
> password-verification. how does sudo treat the system?
> has anyone an answer to that so i can understand it?
[EMAIL PROTECTED]:~$ ls -l `which sudo`
-rwsr-xr-x 2 root root 91700 2006-04-15 07:39 /usr/bin/sudo
That 's' permission in the user execution bit position means the
program runs set-UID under the file owner's account (in this case,
root). To run things as users other than root, the program calls
setuid(2) or similar to drop its root privs (review the source to
see if they roll their own). Honestly, all of your questions and
misconceptions about sudo(1), how it works/what it does, would be
far more easily answered by reading the manual, rather than asking
debian-mentors subscribers to read it to you. See also the sudo
webpage:
http://www.sudo.ws/
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian: user-request-daemon (it could solve some problems)
On Tue, Feb 27, 2007 at 09:21:56PM +0100, Curt Manucredo wrote:
[...]
> but anyway, next time i can not fall asleep i will ask YOU to read ME
> some manpages ;-)
[...]
My apologies for sounding harsh, but these are basic security
concepts that are fundamental to being able to safely provide
privileged programmatic access to resources as another user. That
sort of application is a serious security risk waiting to happen,
and is in no way a task for a novice programmer. Given the years of
testing and fixes applied to sudo to try and make it a safe
solution, you would do well to review its current source and
historical security holes so as to be at least slightly more certain
you're not making the same mistakes they did (learning from the
past). Distributing software designed to provide controlled
privilege escalation is not something to be taken lightly, though
obviously what you do on your computer is none of my business.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Packaging for Debian
On Wed, Apr 18, 2007 at 09:58:00AM -0300, John Hood wrote:
[...]
> 1. http://tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/
[...]
This is a quick hack for when you have already-compiled software you
want to package for personal use on Debian (commercial applications
or the like).
> 2. http://www.debian.org/doc/maint-guide/
[...]
This document describes how to properly package software for
inclusion into Debian, or when you want to have packages that are
rebuildable from a source package in an automated fashion.
If the latter is your goal, subscribing to the debian-mentors
mailing list to ask questions (after first searching through the
list archives for your answer) is highly recommended. Also, there's
much fine documentation to this end available from:
http://mentors.debian.net/
Hope that helps!
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: zfs-fuse packaging
On Wed, May 09, 2007 at 07:10:48PM -0400, Bryan Donlan wrote:
[...]
> primitives are available for sparc64 as well, but this doesn't
> seem to be an architecture supported by debian - or does it have a
> different name?
[...]
Debian's sparc port supports 64-bit on capable hardware, to my
knowledge. You just need an appropriate kernel and libs installed
(kernel-image-2.6-sparc64, libc6-sparc64, et cetera). A message to
the port-sparc list would surely get you an more definitive answer.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libtomcrypt
On Sun, May 20, 2007 at 04:07:13AM +0200, Pau Garcia i Quiles wrote:
[...]
> an OpenSSH-like library
[...]
What you describe sounds a lot more like OpenSSL than OpenSSH.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package name conflicts with oldstable [was: RFS: lsh...]
On Sun, May 27, 2007 at 01:27:37PM +0200, Magnus Holmgren wrote:
[...]
> Technical question: Will things get messed up by renaming the
> source package now? The old lsh (the "light" or "baby" shell lsh)
> is still in oldstable - do we have to wait until sarge is
> archived?
[...]
I'm in a similar situation with the weather-util package. Upstream
(also me) releases it as just "weather" and the package installs a
command line utility /usr/bin/weather (though a weather-util symlink
is added so as not to confuse people who assume package name == what
you run). The only reason I packaged it as "weather-util" is that
there's already a completely unrelated "weather" package in
sarge/non-free (interactive fiction data in the games section). It
was uploaded once in 2001, updated by the QA team in 2004, and was
part of a mass-removal from sid in 2005 (#317416). My reading of the
removal bug would suggest that it will be automatically purged from
the package pool either once sarge is archived or maybe when lenny
is released. It would be nice to be able to rename the weather-util
package to weather, but I honestly have no idea when this will be
possible (now? ever?), nor whether it would even be worth the
hassle. Thus I, too, am interested in comments on Magnus's query.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package name conflicts with oldstable [was: RFS: lsh...]
On Thu, May 31, 2007 at 02:08:35PM +0200, Magnus Holmgren wrote:
> The difference is that in your case the other source package is
> called "if-transition", so there should be no technical reason
> stopping you from renaming your package "weather".
>From an archive/build standpoint, I agree. It would, however,
possibly result in users of oldstable getting the former replaced
with the latter if it (and its dependencies) stuck around during an
upgrade, so I understand the need to, at a minimum, have one release
between removal and reuse of the same binary package name. I just
didn't know if there were additional requirements for waiting until
the release containing the previous package was archived (but I knew
there was no point in addressing it until Etch was released either
way).
> Only perhaps that "weather" may be too generic a name.
Command-line Unix utilities have a tradition of using relatively
generic executable names, and thus matching package names to cut
down on confusion (ex: dict, units). That aside, I get your point...
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Nagios version
On Fri, Jul 20, 2007 at 05:23:20PM +0200, David Dumortier wrote:
[...]
> But I'm a bit confused about the version of the Debian package. Is
> there a licence problem about the version upload ?
[...]
> so I might help for a new release more recent of nagios.
[...]
What version are you looking for? The latest stable Nagios release
(2.9) is packaged and in the archive (apt-get install nagios2). Are
you looking to have a nagios3 package maintained in experimental or
something?
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Nagios version
On Mon, Jul 23, 2007 at 06:45:54PM +0200, David Dumortier wrote:
[...]
> - for installation I have perms on directories to set, must I put them
> on nagiosgraph.postinst ?
man dh_fixperms
> - what about the version's number ? must I put a 0.9.0 as
> nagiosgraph's version or must I take a 0.9.0-0.1 for the Debian's
> version ?
[...]
Using 0.9.0-0 or 0.9.0-1 is convention (everything before the hyphen
should be upstream's version, everything after is the Debian package
revision). Using a multipart package revision such as 0.9.0-1.1
implies a non-maintainer update to the maintainer's 0.9.0-1 package.
I recommend a re-read of the Debian New Maintainers' Guide
(available in the documentation area of the Debian website or in the
maint-guide package).
> - most important, nagiosgraph is under creative licence, is it a good
> licence (I think about Debian policy) ?
[...]
Software distributed under the OSI Artistic License (mentioned from
the project's README) is generally considered free to go into
Debian's main section. Do not confuse this (as you appear to perhaps
have done) with the Creative Commons licenses, some (most?) of which
are considered problematic for inclusion in main.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: centerim (updated package)
On Thu, Aug 02, 2007 at 08:53:52PM -0500, Anibal Avelar wrote:
[...]
> I am looking for a sponsor for the new version 4.22.1-2
> of my package "centerim".
>
> It builds these binary packages:
> centericq - transitional package for centerim
[...]
If only I were a Debian Developer... As an avid long-time user of
centericq myself, I certainly hope you find a sponsor. There aren't
a lot of other options for multi-protocol instant messaging in a
text console, and centericq has been stale (as a project with
upstream bugs) for far too long.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RHS: libterm-ansicolor-ruby
On Tue, Aug 14, 2007 at 09:53:12PM +0200, Nico Golde wrote:
> I am a bit curious why should someone not want to use curses
> but ansi escapes in ruby?
While curses is great for talking to terminals or terminal-like
devices/applications, there are times when you may need to send bare
ANSI or similar escape sequences to non-terminal-like destinations
(files, raw sockets, et cetera). At least in C and Python (not a
Ruby fellow myself), I've not had a lot of luck using curses
libraries/modules to talk to anything that didn't look like a
terminal.
Of course, I can't imagine an ANSI library would be anything more
than a few dozen string constant definitions, unless you wanted
routines to recognize and condense inefficient ANSI sequences into
something denser, consisting of fewer characters (most the ANSI art
apps create some extremely verbose/pedantic strings which can be
distilled quite a lot).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Duplicate file names? (was Re: RFS: ifstat (updated package))
On Tue, Aug 14, 2007 at 07:30:41PM -0400, Robert James Clay wrote:
> Would I be correct in thinking that it is a bug for files of the
> same name to come from different packages? I ask because there is
> another "ifstat" file in Debian; it's from the ifcico package &
> gets installed in a different directory. There is also an issue
> with the man page; I was thinking of doing a man page for the
> ifcico ifstat program (there doesn't seem to be one) but the other
> ifstat does install one...
The ifstat package provides /usr/bin/ifstat and the ifcico package
provides /usr/lib/ifmail/ifstat so I wouldn't expect a conflict
there (as long as anything needing the executable from ifcico has
that path hard-coded or pre-empting /usr/bin as necessary). The
manpage for the former is in section 1 and the manpage for the
latter would go in section 8 if consistent with the manpages for the
other stuff in /usr/lib/ifmail, so again no conflict (though users
with both installed will need to specify 'man 8 ifstat' to see the
one from ifcico).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RHS: libterm-ansicolor-ruby
On Wed, Aug 15, 2007 at 04:02:57PM -, Thomas Dickey wrote:
[...]
> (no point in hardcoding "a few dozen string" definitions, unless
> one _likes_ the nasty comments that people make when they read the
> code ;-)
Completely agree. My point was that, when I've *needed* ANSI color
and similar capabilities in an application where I didn't want to
(or couldn't) use curses, I've usually coded the necessary
definitions into whatever custom Python module I wrote to do display
handling, or set up macros in a C header, and it's not exactly been
a burdensome amount of code to throw together from scratch.
That's not to say that I wouldn't be thrilled if Python upstream
started to carry these definitions as part of its core modules (like
they do with, say, Telnet IAC sequences). Closest I can find is
definitions like curses.ascii.ESC, curses.COLOR_RED and
curses.A_NORMAL... I could hack those (wrapped with chr() or str()
calls where appropriate) into my colorize functions in place of some
of my constants, but that would be even uglier in my opinion.
Anyway, time for me to stop derailing the discussion (pun intended).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RHS: libterm-ansicolor-ruby
On Wed, Aug 15, 2007 at 12:38:07PM -0700, Russ Allbery wrote:
> Thomas Dickey <[EMAIL PROTECTED]> writes:
>
> > (no point in hardcoding "a few dozen string" definitions, unless one
> > _likes_ the nasty comments that people make when they read the code ;-)
I took Thomas's comment to mean that it *should* be in a library (or
at least abstracted somewhere reusable), rather than hardcoded into
your apps. Sounds like violent agreement to me. ;)
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to start porting to a new ARCHITECTURE?
On Wed, Sep 19, 2007 at 03:26:37PM +0200, Michelle Konzack wrote:
> Am 2007-09-17 19:46:20, schrieb David Given:
[...]
> > Now you have both a compiler and a kernel, you can use your
> > compiler to generate a userland --- as set of basic binaries to
> > get your system up and running --- and then boot your new
> > system. This isn't too difficult, although cross-compiling on
> > gcc has its own horrors.
> >
> > Once you've got it reliably self-hosted, you're most of the way
> > there --- setting up a basic Debian port is relatively
> > straightforward.
>
> "Self-Hosted" is "my" target since I have had MANY horrors with
> cross-compiling
[...]
Having never done it myself, take this with a grain of salt, but my
understanding is that you should really only use the cross-complied
system to bootstrap your port to the point where you can recompile
it all natively, then use the resulting native system to recomplie
it all again, just to be 100% sure. From there, you have the hard
part out of the way (hopefully) and can focus on the usual
arch-specific bugs in your desired applications.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mentors.debian.net reloading
On Fri, Oct 26, 2007 at 10:34:03PM +0200, Cyril Brulebois wrote:
[...]
> I'd better see the possibility of getting an access to the offending
> archs to try and figure out what the problems are and to fix them.
> Depending on the archs, it can be easy to get an account (hppa is a very
> good example, thanks to the available clusters), or it can be very
> tricky; in that latter case, emulation can help a lot.
I went to the extreme of trying to collect and maintain Debian on an
actual physical representative from each supported architecture (I'm
up to 9 now, missing arm, ia64 and s390 still), and can say from
experience that it's neither a simple nor entirely cheap
alternative.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
vanity packages (was: mentors.debian.net reloading)
On Sun, Oct 28, 2007 at 09:19:12PM +, Neil Williams wrote:
[...]
> What kind of popcon score? i.e. does anyone else think it is a useful
> addition?
I would consider its popularity low (187 popcon installs with 46
votes). Admittedly, Russ sponsored it because he said thought he was
likely to find it useful. If it's consensus among the Debian
community, or even merely the opinion of my sponsor, that the
package I currently maintain is of little enough worth as not to
outweigh its drain on (security team, mirror operator, release
management) resources, I would certainly not protest its removal.
Still, I will potentially be looking to maintain more of my projects
within Debian, as they reach functional maturity, and may then
revisit entering NM; but for now it seems unnecessary given my
limited availability to participate in a more project-centric
capacity, attend conferences and so on (I know none of that is
*necessary* to be a DD, but I take any comittment, even those of a
voluntary nature, very seriously).
At any rate, the goal was not to talk about myself per se (as I
entertain no illusions that either I or my work is of any great
value to Debian, nor will I claim to be more than even a marginal
example in favor of my point), but merely to stand up and be
counted. I don't expect to sway your opinion that only packages
maintained by people intent on becoming official DDs are of any
quality or worth; but just as you seemed inclined to provide it, I
felt compelled to present a counter-argument against such broad
generalization.
In recent years, I have seen several discussions on devel in which
it was suggested that the number of DDs is unnecessarily high, and
that it's entirely possible to provide a wide variety of valuable
resources to the project without requiring official DD status. These
arguments seemed (to me) quite cogent, just as have the arguments
suggesting the number of packages in main is unnecessarily high. If
you (or others) feel that I am "part of the problem," I suppose I'll
just have to live with that.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Flash in debian
On 2012-01-28 17:14:46 +0100 (+0100), Christian Welzel wrote:
[...]
> flex-sdk is licensed unter MPL 1.1
[...]
It's actually the above assertion which is in question and in the
process of being verified, based on my reading.
> The problem is, that the MPL-licensed flex-sdk is not (yet) packaged
> for debian
[...]
And it appears the submitter of that ITP is in contact with Adobe as
of a few weeks ago to hopefully resolve contradictory licensing
statements. IF flex-sdk does turn out to be MPL as suggested, then
your package might be suitable for contrib until such time as
flex-sdk enters main. It would probably make more sense to just wait
and see how that discussion with Adobe plays out first though.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120128162442.gd...@yuggoth.org
Re: Flash in debian
On 2012-01-28 08:50:32 -0800 (-0800), Joey Parrish wrote:
[...]
> As it stood from Adobe, you had to get the source from SVN, but it
> was full of 1) binaries, 2) forked versions of standard Java libs,
> and 3) outdated versions of standard Java libs. All of these
> things were required in some mix to get the thing to build, and
> all of them are problematic. Adobe builds their binaries in a very
> specific cygwin environment, from what I've been able to discern.
[...]
Certainly doesn't make me want to use Flash for anything I write
(not that there's any shortage of other reasons to feel that way
already).
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120128180934.ge...@yuggoth.org
Re: Any script to populate debian/copyright file ?
On 2012-07-16 10:35:03 -0400 (-0400), Aliaksei Sheshka wrote:
> Sorry, but not helpful. They only represent ~13% on nearly default
> Wheezy setup
[...]
While still not a perfect example, my weather-util package has
ISC-licensed and public domain components...
http://packages.debian.org/changelogs/pool/main/w/weather-util/weather-util_2.0-1/weather-util.copyright
Hope that helps clarify the format a little!
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120716144908.gn3...@yuggoth.org
Re: issues with packaging Clozure Common Lisp (ccl.clozure.com) for Debian
On 2012-07-17 11:38:32 +0530 (+0530), Faheem Mitha wrote:
[...]
> CCL requires itself to build. Since it is not currently in the
> Debian archive, that raises the question of how this should
> happen.
[...]
Having not done this myself, I've seen it discussed ad nauseum on
debian-devel over the years. First you have to work out how to
bootstrap the compiler on each arch you're targeting. Most compilers
have a minimal bootstrapping method documented using another
compiler (C or in CCL's case perhaps another CL compiler). As a
non-DD you'd likely need to work closely with someone with access to
porter boxes for the various architectures, even if only to help
test cross-built binary versions of CCL (hopefully it comes with a
good set of automated validation tests?). Testing is essential for
something like a compiler, because you want to have some
confirmation your package build sequence works everywhere and won't
be as likely to annoy the buildd admins or porters with a bunch of
arch-specific FTBFS problems.
Once you manually work out how to get your CCL packages building
reliably, you'd coordinate closely with a sponsor (maybe someone
from the Debian Common Lisp Team?) to get temporary/throwaway binary
packages uploaded for each arch so that they can be subsequently
pulled in on the buildds as a build-depends of your proper
source-built packages.
The last time I remember this coming up, I believe it was in
reference to (or resulted in) a GSOC project as well as Wookey's
Bootstrapable Debian talk at Debconf11. A redux of this core "staged
builds" idea seems to be documented here, though bootstrapping
individual compilers is mentioned only briefly and the context is
centered more around bringing up an entire new port of Debian from
source:
http://wiki.debian.org/DebianBootstrap
I'm not sure how much closer that's gotten to being a usable
proposal yet. I hunted around for documentation specific to
introducing a new self-building compiler package into Debian, but
didn't have much luck. Hopefully one of the DDs on this list can
point you to something slightly more appropriate.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120717122850.go3...@yuggoth.org
Re: Correct way to copy files to /home/$user?
On 2012-07-25 15:21:51 + (+), adrelanos wrote:
> I want to create a new package xchat-privacy. Actually no binary files
> need to be installed/replaced. Only a few configuration files have to be
> replaced, such as ~/xchat2/xchat.conf, ~/xchat2/ignore.conf, etc.
>
> What is the correct way to copy files to /home/$user?
You probably want to work with xchat upstream and the current xchat
package maintainer in Debian to get those extra configuration files
distributed as part of the application (maybe installed at
/usr/share/doc/xchat/examples or a similar path). Couple this with
additions to xchat's documentation to direct users to copy those
files to their homedirs if desired, or maybe additional CLI flags to
cause xchat to source them from a separate location in /etc instead.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120725154920.gk3...@yuggoth.org
Re: RFS: xinetd
On 2012-08-04 19:22:26 +0200 (+0200), Salvo Tomaselli wrote:
> I knew it wasn't going to be into testing soon and it was ok with
> me, but now i am not sure wether compiling with the new hardening
> options is a good reason for asking a freeze exception or not.
Generally, you should only seek a freeze exception for an upload
containing strictly backported fixes for RC bugs and release goals.
New upstream versions, minor bug fixes and packaging improvements
should be omitted if you're targeting the release.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120804173330.gz3...@yuggoth.org
Re: Interaction between m.d.n. and Ubuntu
On 2012-09-07 22:32:09 +0300 (+0300), Boris Pek wrote:
[...]
> I need to upload updated package with Ubuntu-specific patch. This
> package will be uploaded into Ubuntu by avoiding Debian archive.
Wouldn't an Ubuntu PPA be more appropriate for that use case? How
does uploading Ubuntu-specific packages to Debian's MDN help with
getting them sponsored directly into Ubuntu?
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120907194321.gm6...@yuggoth.org
Re: Interaction between m.d.n. and Ubuntu
On 2012-09-07 22:57:09 +0300 (+0300), Boris Pek wrote:
[...]
> I usually maintain packages for Debian. But now faced with necessary
> to do Ubuntu-specific update. And usual way of exchanging files is
> not working.
In the past when I've been in that situation, I just open a bug in
Launchpad against Ubuntu's version of my package and include a patch
for them to apply. Pointing the bug to an Ubuntu-specific branch on
your public revision control might be even niftier (if you're
maintaining one). I've never investigated the Ubuntu equivalent of
Debian's mentoring/sponsoring processes (or at least can't remember
how it works), but I think there are some dual Debian/Ubuntu devs on
this list who could chime in.
> Could you suggest any free hosting where I can put source package
> files and they will be available using dget?
Unfortunately no, I usually just serve them off my home Internet
connection when I need to do that, but I'm also a sysadmin by trade.
I guess you don't have a personal Web site you could drop those
files on temporarily? AFAIK, dget doesn't need any fancy
repository... just drop the .dsc and tarballs/diffs for your source
package in the same path together.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120907202634.go6...@yuggoth.org
Re: RFS: opendchub (updated package)
On Thu, Aug 27, 2009 at 08:36:05AM +0800, Zak B. Elep wrote:
[...]
> What really goes on here is that there's a stronger preference towards
> having patches in debian/patches/ m as it is a particular convenience
> for maintainers, as opposed to navigating the source tree for diffs. I
> don't object to this at all, as long as it doesn't break my maintaining
> the package.
[...]
Not necessarily a convenience for the current maintainer (indeed,
you have yourself expressed an alternative preference), but rather
possible future maintainers in your absence, including the security
and QA teams.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: personal debian package repository
On Wed, Sep 02, 2009 at 10:19:15AM -0700, Don Raikes wrote:
> This may seem like an odd question, but I am working on some
> debian packages, and would like to put them onto a personal
> package repository so that I can include them in a liveCD I
> maintain.
[...]
I do this (assumed apt-ftparchive is installed and the debs and
source packages are in your cwd, and local gpg has access to your
signing key):
rm -f Contents.bz2 Contents.gz Packages.bz2 Packages.gz Release Release.gpg
Sources.bz2 Sources.gz
apt-ftparchive contents . > Contents
bzip2 -k Contents
gzip -9 Contents
apt-ftparchive packages . > Packages
bzip2 -k Packages
gzip -9c Packages > Packages.gz
apt-ftparchive sources . > Sources
bzip2 -k Sources
gzip -9c Sources > Sources.gz
apt-ftparchive release . > Release
rm Packages Sources
gpg --armor --default-key ="Jeremy Stanley " --detach-sign
--output Release.gpg Release
Stick the results on any old webserver and use this path in the
sources.list:
deb http://fungi.yuggoth.org/path/to/debs ./
Hope that helps!
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: About software from other distribution
On Tue, Nov 10, 2009 at 11:04:49AM -0600, Boyd Stephen Smith Jr. wrote:
[...]
> Or, (ala PINE) the copyright holder could have an odd view of a
> normally acceptable license.
[...]
A less useful example these days, now that recent versions of PINE
(circa Alpine 1.0 in late 2007) are released under the Apache
License:
http://www.washington.edu/alpine/overview/story.html
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Writing manpages
On Wed, Nov 18, 2009 at 08:56:10PM +1100, Ben Finney wrote:
> Type the page as a reStructuredText document, then render it to a
> manpage with ‘rst2man’
[...]
Awesome! This thread already had me thinking, "There should be a
reST to TROFF/GROFF path--if there's not I guess I'll write one." I,
too, had resolved recently to start maintaining all my project
documentation in reST. Not that I find building/editing manpages
directly in vi to be that hard, but it's still laborious and
time-consuming. I'll be happy to contribute fixes to this for any
bugs I find. Thanks for the rcommendation!
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: shc
On Thu, Dec 03, 2009 at 10:48:43PM +0200, George Danchev wrote:
> This package is not for us ;-)
[...]
For those who missed the thread on debian-devel, Dario withdrew his
ITP yesterday for similar reasons:
http://lists.debian.org/debian-devel/2009/12/msg00023.html
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fuppes: Package Names and the Separation of a Project into Packages
On Sat, Dec 19, 2009 at 02:18:22PM +0100, Christoph Egger wrote:
> Hm I'd first consider the size of each of the plugin packages. If
> they're relatively small you could consider grouping them, seems
> like that it is already somewhat done in core, database, encoder,
> metadata, ... if these are not depending on each other it could be
> a sensible choice. If they're really small all in one is ok as
> well.
Equally important in this decision is the size and number of
dependencies for each package. While the packages themselves may be
small, the fine-grained split may have been intended more to avoid
the user installing a ton of dependencies for particular features
they didn't need anyway.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: what between ITP and RFS ?
On Thu, Jan 21, 2010 at 06:12:16PM +0100, Mike Hommey wrote:
> Why not Cc the ITP bug when you send your RFS on -mentors ?
FWIW, I do that (see http://bugs.debian.org/364317 for example)
because, frankly, it seems like the obvious thing to do...
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Custom packages derived from Debian Source Packages
On Tue, Jan 26, 2010 at 09:20:34PM +0100, Erik Schanze wrote:
[...]
> I'm a bit lost to find a way which is compatible to Debian archive and
> packages that are easy to maintain and to follow Debian versions
> (mostly security fixes).
[...]
Have your custom repository use a different distribution name and
employ pinning to increase its priority over the standard
distributions?
http://wiki.debian.org/HowToSetupADebianRepository
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: original package changelogs
On Sun, Jan 10, 2010 at 10:58:01PM +0800, Paul Wise wrote:
[...]
> If you use a version control system, there are cvs2cl, svn2cl, git2cl
> and probably other scripts to convert your commit messages into
> GNU-style ChangeLog files, no need to reinvent the wheel here.
[...]
I did anyway--using GitPython (python-git package), it took about 15
minutes:
http://mudpy.org/res/git2gch
I checked out git2cl later, but I wasn't that pleased with its
output. To some extent, it will depend on your workflow and to what
extent you preformat your commit messages...
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: A meager copyright. Remotely acceptable?
On Thu, Apr 01, 2010 at 02:37:56PM +0200, Mats Erik Andersson wrote:
[...]
> That leaves __one_single__ file (oftpd-0.3.7/COPYING) expressing a
> claim of copyright. The text is below reproduced verbatim. As far
> as I can understand the text there seems to yield no possiblility to
> relate this to GPL, and to no other DFSG-compliant license either.
> Am I correct in this observation?
[...]
That's the 2-Clause BSD license:
http://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29
I used to use it for my projects before I switched them to the ISC
license (functionally the same but with more terse wording). It is
both DFSG-free and GPL-compatable, FWIW.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100401195434.gw1...@yuggoth.org
Re: pycentral vs pysupport?
On Mon, May 10, 2010 at 06:52:42PM +0200, Jakub Wilk wrote:
> You should use python-support.
Yes... in fact, if you use of DH7's rules.tiny example, it will make
python-support fairly automatic (assuming you don't have
particularly unusual build requirements).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100510171112.gq5...@yuggoth.org
Re: Fwd: failed hppa build of aqsis 1.6.0-1.2
On Wed, Jun 30, 2010 at 03:20:10PM +0200, Manuel A. Fernandez Montecelo wrote:
> Can anybody tell me what I'm supposed to do with this?
>
> It builds fine in the rest of architectures:
> https://buildd.debian.org/pkg.cgi?pkg=aqsis
>
> And the log doesn't say anything interesting about what the failure is...
> it's like the process was in an infinite loop, or maybe killed by some
> segfault or something...
[...]
You might also ask on debian-h...@ldo in case someone there is
willing to provide assistance debugging it on the platform. Since
it's a graphical app, I'm guessing a build on my 712/60 is probably
out of the question but there are others with more powerful systems
or access to the porter boxes.
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100630200523.gt2...@yuggoth.org
Re: Fwd: failed hppa build of aqsis 1.6.0-1.2
On Wed, Jun 30, 2010 at 11:41:53PM +0200, Manuel A. Fernandez Montecelo wrote:
[...]
> It takes about ~10 minutes to compile in my 2 year old, dual core
> not very powerful laptop. I don't know how hppa compares to these
> ones, but just in case, buildd official times are:
>
> mipsel: Build needed 00:52:51, 264392k disc space
> armel:Build needed 06:53:56, 266224k disc space
> i386: Build needed 00:07:44, 248728k disc space
> ia64: Build needed 00:39:33, 405948k disc space
[...]
Hmm... yeah, my 712/60 has about that much available space on its 1G
SCSI drive, but only a 60MHz CPU and 32MiB of RAM. I compile small
utilities and applications on it in a matter of 5-10 minutes which
take all of a few seconds on my faster systems. Chances are this
would take hours if it even completed at all. It's not quite as slow
as my Mac Quadra, but it's pretty close. As I said, the HPPA porters
probably have access to suitable hardware for replicating this
problem (but I definitely don't).
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100630221511.gu2...@yuggoth.org
Re: Package Configuration
On Thu, Aug 19, 2010 at 02:35:13PM +0100, Chris Baines wrote:
> Sorry for the ambiguous message subject, one of the packages I am
> building creates configuration files in the users home directory.
> However when I purge the package these files do not get deleted.
>
> Does anyone know where I can find the relevant Debian documentation
> describing how to setup the package so that it behaves as expected? Does
> anyone know of any packages with this kind of setup so I can have an
> example to work off?
Package scripts shouldn't ever mess directly with files in homedirs.
It's fine that the packaged application itself may create user
configuration and may even remove user configuration, but the
packaging must not. It's simply a fact of life that if you install
some packaged application and run it, and then uninstall that
application later, you're likely to have cruft in your home
directory.
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100819135809.ga2...@yuggoth.org
Re: Package Configuration
On Thu, Aug 19, 2010 at 03:11:50PM +0100, Chris Baines wrote:
> Ok, that makes my work easier. Still surprising though, I thought
> the dpkg purge command was meant to as the man page says "remove
> everything". Obviously it cant do this if the home directory is
> off limits.
If you can find where you read that statement, and if it was an
official Debian document, a bug report and patch proposal are in
order to clarify this point.
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100819142449.gb2...@yuggoth.org
Re: Package Configuration
On Thu, Aug 19, 2010 at 02:24:51PM +, The Fungi wrote:
> On Thu, Aug 19, 2010 at 03:11:50PM +0100, Chris Baines wrote:
> > Ok, that makes my work easier. Still surprising though, I thought
> > the dpkg purge command was meant to as the man page says "remove
> > everything". Obviously it cant do this if the home directory is
> > off limits.
>
> If you can find where you read that statement, and if it was an
> official Debian document, a bug report and patch proposal are in
> order to clarify this point.
Sorry, you said right there "dpkg [...] man page." I should read more
closely.
[...]
purge: The package is selected to be purged (i.e. we want to
remove everything, even configuration files).
[...]
Note: some configuration files might be unknown to dpkg because
they are created and handled separately through the configuration
scripts. In that case, dpkg won't remove them by itself, but the
package's postrm script (which is called by dpkg), has to take
care of their removal during purge.
[...]
Agreed--this is misleading, and clarification is probably in order.
File a minor/wishlist bug against dpkg (or I'll be happy to if you
prefer).
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100819143608.gc2...@yuggoth.org
Re: Package Configuration
On Thu, Aug 19, 2010 at 04:36:49PM +0100, Chris Baines wrote:
> I would be happy for you to file a bug as I am not that familiar with
> the Debian policy on this, and have little experience filing bugs.
Done. See http://bugs.debian.org/593628 and follow up to
593...@bugs.debian.org if you like.
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100819180227.gd2...@yuggoth.org
Re: packaging help
On Thu, Sep 02, 2010 at 09:07:26AM -0700, Gobelli, Marcelo wrote:
> Maybe you can point me to a *reliable* tutorial for debian
> packaging.
[...]
The Debian New Maintainer's Guide is the most recommended:
http://www.debian.org/doc/maint-guide/
The debian-mentors FAQ also has some useful things to say on the
topic:
http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#packaging
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100902163433.gm2...@yuggoth.org
Re: question about proprietary libraries
On Thu, Sep 02, 2010 at 12:46:09PM -0400, Stephen Sinclair wrote:
[...]
> I will assume for now that the vendor's policy is to allow people
> to distribute their header files, since otherwise I can't think of
> any legal way to write open source software that would use their
> device.
Do you have a (legally sound) reason to believe that the vendor even
cares whether people write open source software for this device? For
that matter, do you know that their header files aren't licensed to
them by some non-transferrable agreement which allows the vendor to
provide a copy to you but doesn't entitle you to pass them along to
anyone else?
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100902171057.gn2...@yuggoth.org
Re: policy for location of web content - application uploaded images
On Mon, Sep 13, 2010 at 12:44:56PM -0500, Karl Schmidt wrote:
> wordpress uses /srv/www/.../uploaded pictures
> mediawiki uses /var/lib/mediawiki/images/
>
> Seems like wordpress is doing this correctly - from fhs - /var/lib is for
> "variable state information"
>
> and "/srv : Data for services provided by this system"
This comes up frequently on debian-devel (the most recent thread I
recall being just a few weeks ago
http://lists.debian.org/debian-devel/2010/08/msg00347.html ), and
consensus is that packaging and packaged software should not touch
/srv by default, but should allow the admin to configure things to
write into /srv if deemed relevant.
Straight from the horse's mouth:
[...]
no program should rely on a specific subdirectory structure of
/srv existing or data necessarily being stored in /srv
[...]
http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/srv.html
If an application has a need to write data to the system which
should remain there indefinitely so it can access it again later,
and which can't be easily/quickly regenerated by that application,
it should go into the /var/lib directory heirarchy by default. Data
uploaded by users through a Web UI provided by a packaged
application seems to me to fit this description.
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100913192903.gy2...@yuggoth.org
Re: Doubts in Sigar packaging
On Wed, Sep 15, 2010 at 03:18:20PM +0200, Adam Borowski wrote:
[...]
> I recommend against using dates to mark revisions, since there probably
> will be multiple commits in a single day, so there is no way to tell
> which exactly version you did package.
[...]
On one project where I'm upstream (not packaged for Debian
currently), I use seconds since the epoch from the last git commit
for a minor versioning component on tarballed development snapshots,
which at least reduces this problem down to multiple commits within
the same second rather than within the same day. On my project,
there's not enough churn to make this a relevant concern for now, I
don't care about human readability, and it's only an extra two
digits more than you need for an ISO 8601 date.
One related concern for some projects, however, is whether releasing
from different, out-of-sync VCS branches could make timestamp-only
version numbers appear to skip backwards under such a scheme. Making
sure your major version numbers are human-assigned is an important
component, obviously. ;)
--
{ IRL(Jeremy_Stanley); PGP(97AE496FC02DEC9FC353B2E748F9961143495829);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100915165858.ga2...@yuggoth.org
Re: Open RFS lacking (further) response
On Fri, Oct 29, 2010 at 10:44:37PM +0100, Noel David Torres Taño wrote:
[...]
> Is it always an upstream package worst than a repackaged package?
[...]
>From what I've seen, in most cases, yes.
I am one of the guilty "one pet package" upstream authors who gets
my Debian work uploaded by a gracious sponsor. I also have a
"special interest" in Debian as a whole, since it's been my primary
operating system as far back as the bo release and I run it on
roughly 10 distinct hardware architectures (including hundreds of
servers at my place of employment).
I spent substantial time learning the proper way to package
applications for Debian and lurked on this list for over a year
before requesting sponsorship. Debian policy and standards are a
moving target. Paying attention to debian-devel-announce and
(preferably) debian-devel are important for me to proactively stay
abrest of issues and transitions which could affect my package.
Keeping up with Debian's bug tracker is crucial as well.
I try to contribute in other ways, participating in ML discussions
within my field of expertise, diligently filing detailed bugs (and
when possible providing patches) any time I encounter an
undocumented issue, and advocating Debian within my technical
community. On several occasions I've gotten close to submitting
packages of other upstreams' work or even applying for a DM/DD role
in the project, but I'm mindful of the limited spare time I have in
my life and careful not to commit to responsibilities beyond my
present capacity.
Even with a "special interest in Debian" I am fairly certain my
*one* package would be improved if repackaged by an experienced
Debian Developer.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101030001619.gb8...@yuggoth.org
Re: Open RFS lacking (further) response
On Sat, Oct 30, 2010 at 11:49:25AM +0200, Niels Thykier wrote:
> Personally I believe that Noel's statement is relates to upstream,
> who have their own packaging + their own little repository as
> compared to upstreams like you, who also work on the Debian side.
[...]
Which was more or less my point as well...
I have my own packaging and I publish it in my own repository too.
However, I spent and continue to spend a disproportionate amount of
time making sure my packaging is correct for the Debian project as a
whole (to a great extent because Debian is also my preferred
operating system and the primary reference platform on which I
develop and test my software). I do that by getting my packaging
peer-reviewed on the mentors list, having an official DD upload my
packages once he's comfortable with the level of effort I've
applied, keeping up with Debian's BTS, participating in discussions
here and on debian-devel, et cetera.
In contrast, the packaging I've seen provided by upstreams who don't
actually put forth the effort to get involved to that degree are
pretty much always non-compliant with Debian standards... many FTBFS
on sid (if they even publish source packages at all), most do not
have proper Debian.changelogs with BTS-relevant closes fields, lots
are ignorant of the FHS or more Debian-specific policy directives,
few run them through QA filters like lintian or test their builds in
clean chroots... I won't even bother to enumerate the more
scary/egregious/brain-dead packaging no-nos I've seen from some.
I expect it would be less work for a seasoned DD or DM to simply
disregard the upstream-provided packaging and redo it from scratch
than try to hunt through it for those kinds of land mines. If it
were my software and I weren't submitting my own packaging work
directly into Debian, I wouldn't take it personally if the package
maintainer scrapped my unofficial packaging work and replaced it
with his own.
> On a related note, while an experienced DD (or non-DD for that
> matter) may make a "better" debian package most of them would
> still be an inferior maintainer. All bug reports are handled by
> one who knows the code and the latency of forwarding upstream bugs
> is ... 0!
A lot of that has to do more generally with the responsiveness of
the upstream developers. I personally take bug reports from any
distribution's users of my software seriously, whether or not they
come through the package maintainers. Though I also work a day job
where I constantly get bombarded by harebrained requests from
clueless users, so I'm used to handling some of the worst sorts of
end-user interaction with a smile and a nod (and the open-source
community is more competent and much easier to deal with than my
day-job customers anyway).
Faster bug triage and awareness of upstream software's development
process aside, I still expect DDs who constantly deal with
maintenance of a broad variety of packages have a more useful
perspective on distribution-wide integration which I lack.
> Personally I think you should have an extra look at the DM role.
> You may not be ready for it just yet, but I think aiming for it
> would be an improvement for you. :)
[...]
It's been on my to do list to look into, but I haven't yet gone out
of my way to pinopint any of my local DDs... no doubt there are many
here near RTP where I live, even though Raleigh is more of a Red Hat
town. I figured I'd revisit the DM process once I found an
opportunity to get a DD signature or two on my key. Also, lack of
some official status hasn't yet been an obstacle for contributing to
Debian in a variety of other ways, so I haven't seen it as a
particularly immediate need. On the other hand, given that I've been
participating in the project in an unofficial capacity for over a
decade, maybe it's time.
Thanks for the suggestion and kind words!
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101031171757.gg8...@yuggoth.org
Re: package transition question
On Wed, Nov 03, 2010 at 11:59:27AM +0100, Harald Jenny wrote:
[...]
> Our current idea is to do the installation, run the program in
> postinst to check for config errors and if we find some we issue a
> warning message and cease to restart the daemon - or does anybody
> have a better idea?
Basically the same, just more reusable, would be to check the
configuration as part of the start/restart/reload sections of the
new version's initscript. I believe this is the same mechanism
Apache has been using for years to help prevent killing httpd when
you try to reload a broken configuration without validating its
syntax (or when some of its dependent pieces may have gone missing).
Obviously this still leaves the admin in the unfortunate position of
having to solve his configuration problem on the spot or roll back
to a previous package version.
Alternatives would be (more user friendly) come up with a
configuration translator if all existing options can have a 1-to-1
transform/mapping to new options or syntax, or (less user friendly)
change package names with the new version and upload a final-ish
package of the old version which displays loud messages about what
the new package name is and how to manually transition to it.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101103122558.gq8...@yuggoth.org
Re: RFS: rgbpaint
On Wed, Jan 12, 2011 at 12:49:35AM +0100, Muammar El Khatib wrote:
[...]
> 1.1) There is an error in the link provided in the
> Format-Specification field:
> http://sv.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
>
> It should be:
> http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
[...]
If you're going into that, I'd recommend checking out the DEP5 tread
from debian-devel earlier this week:
http://lists.debian.org/debian-devel/2011/01/msg00230.html
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112003214.gc1...@yuggoth.org
Re: RFS: rgbpaint
On Wed, Jan 12, 2011 at 02:47:28AM +0100, Jakub Wilk wrote:
> Uhm, sorry, no, file cannot be used to determine encodings. Besides,
> UTF-8 is a superset of ASCII, so everything is all right according
> to file.
A great example is:
fu...@cthulhu:~$ echo // | file -
/dev/stdin: ASCII C++ program text
Just feeding it a file containing nothing but a pair of slashes is
enough to confuse file(1) into thinking it's C++ source code.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110112035124.gd1...@yuggoth.org
Re: Creating a user/group for a package
On Sun, Jan 30, 2011 at 12:30:08AM +, David Given wrote:
[...]
> at uninstall time neither delete their group, timidity never
> deletes its user at uninstall time at all, and while ssh does
> delete its user, won't this cause problems if orphaned files are
> left with that uid?
[...]
This has been discussed to death in years past, but it's generally
considered more dangerous to delete accounts in package management
than to leave them behind. Not only might the admin have made use of
that account in other ways since installation but, as you point out,
deleting users or groups risks granting files to new users later if
left orphaned and there's not a really sane way to guarantee finding
those during package removal.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110130030225.gg9...@yuggoth.org
Re: Init scripts as conffiles
On Tue, Feb 15, 2011 at 04:33:25PM +, Tony Houghton wrote:
[...]
> I would have thought it would be better to treat them as not to be
> modified by the user/admin; any init configuration should be done via
> /etc/default.
In years gone by, I've frequently had to manually adjust initscript
contents or symlink ordering to deal with issues. The vast majority
of initscripts don't source variables from under /etc/default, and
those which do often lack variables for things like
overriding/augmenting service start options or defining additional
local service interdependencies. If policy were altered to make
initscripts non-conffiles, tons of packages would be insta-buggy (at
least from a wishlist standpoint, if not worse) due to the loss of
admin flexibility.
Also, trying to change a major class of system controls which have
traditionally been considered conffiles to non-conffile status would
be a near impossibility due to the number of installed systems with
existing local modifications.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110215170537.ge1...@yuggoth.org
Re: Init scripts as conffiles
On Tue, Feb 15, 2011 at 05:27:39PM +, Tony Houghton wrote:
> I'd consider packages which require editing of the init script instead
> of using /etc/default or similar to be badly designed at best. I know
> fixing the mass of existing packages would be too big a job, but I
> thought it might be possible to provide a new option in dh_installdeb
> and encourage its use for new packages.
Well, I think there are probably quite a few package maintainers who
simply don't consider that the admin might want to start a daemon in
a different way than what's provided by the initscript. For example,
the daemon in question runs as root:root and I want to wrap it to
run as a specific uid:gid pair I've created for the purpose, or the
initscript only starts one instance of a daemon and I need several
launched all pointing to individual configuration files.
I agree that pretty much all of these use cases would be valid
enough to open wishlist bugs on and include proposed patches, but a
lot of admins just want to change start behavior of a daemon (often
in complex ways not anticipated by the packager) and move on,
without having it clobbered by a stable package update later.
Obviously, when running testing/unstable/experimental or during a
dist-upgrade (and sometimes even the occasional security update),
you still have to pay attention to and manually merge changes in
your locally-modified initscripts, but the same can be said of any
conffile.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110215180545.gf1...@yuggoth.org
Re: what if upstream provides debian build directory
On Fri, Mar 18, 2011 at 08:21:44PM +0100, Harald Dunkel wrote:
> What is Debian's policy, if upstream provides its own debian directory
> or package build procedure?
[...]
> Of course I checked Debian's Policy Manual, but AFAICS this subject
> has been successfully ignored by now. Any helpful comment would be
> highly appreciated.
Not ignored at all... maintainers who find an upstream debian
directory getting in the way (and who are unable to successfully
convince upstream of the inconvenience) usually either repackage the
upstream source to remove it, or use v3 packaging format which
clears and replaces it with the contents of the maintainer's files
when unpacking.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110318194641.gf1...@yuggoth.org
Re: docs are generated on all build machines
On Sat, Apr 02, 2011 at 10:21:57AM +0200, Michael Wild wrote:
[...]
> I'd like the docs only to be built *once* on the build server, not for
> every architecture, since they are architecture independent and building
> them for every architecture would waste hours of time.
[...]
For the moment at least, architecture-independent packages are not
intended to be built on any build server, but should be uploaded
along with your source and the architecture-dependent packages for
whichever architecture you're uploading your original build. This is
signified by declaring the doc package "Architecture: all" rather
than "Architecture: any" in your debian/control file. See section
4.1 of the New Maintainers' Guide and section 5.6.8 of the Debian
Policy Manual:
http://www.debian.org/doc/maint-guide/dreq.en.html#control
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110402134451.gr1...@yuggoth.org
Re: docs are generated on all build machines
On Sat, Apr 02, 2011 at 10:02:19AM -0400, Scott Howard wrote:
> I think his package is already Arch:all.
[...]
Ahh, yes, I had missed the package name/source. I agree your
analysis sounds a far more likely scenario given the problem
description.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110402141237.gs1...@yuggoth.org
Re: creating new package without archive file (e.g. tar.gz)
On Tue, Apr 12, 2011 at 03:49:22PM +0300, Peter Pentchev wrote:
> Agreed. In my packaging, I've been using 0.0.MMDD for that
> purpose - assuming that when/if the upstream developers decide to
> actually roll out a release, they'll use something larger than
> 0.0.1 for a version number :)
While admittedly more recognizable for users of Western calendars,
an 8-digit ISO 8601esque datestamp is fairly low-density. With only
a couple more digits, you can have epoch seconds as your version
timestamp (as upstream, I actually just do 0.0. for
snapshots of some of my not-yet-ready-for-release projects). Just
remember that they'd need to do more than release "something larger
than 0.0.1" to edge out 0.0 something on the order of
0.1.x would be needed.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110412174046.ga1...@yuggoth.org
Re: [Fwd] Bug#621966: hasciicam: FTBFS: hasciicam.c
On Tue, Apr 26, 2011 at 02:28:10AM +0900, Charles Plessy wrote:
> I see that one uploader of hasciicam is Debian Developer. He is
> the first person to contact for upload or to recommend you as
> Debian Maintainer--that is, to give you upload privilege.
Specifically, according to who-uploads, 1.0-1 was uploaded to
unstable by Giunchedi Filippo , so he'd be the
right place to start asking for a new upload. Previous versions were
uploaded by Vincent Bernat and Christian Surchi
, so they may be of some assistance as well.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110425173803.gn1...@yuggoth.org
Re: AGPL (was Re: Please try expo.debian.net)
On Wed, Jul 27, 2011 at 10:06:25PM +0200, Adam Borowski wrote:
> I can't see how someone can claim that AGPL is a free software
> license.
[...]
I was recently reviewing some new software (a FUSE backend) for an
acquaintance who wanted to release it under AGPL3. I did mention to
him the BSD-advertising-clause-like issues with the Affero
provisions in the license, including the additional burdens it
places on derivers of the software who may not reuse pieces of it in
the way he envisioned. More concerning, however, his software also
links against libmysqlclient which (starting with 4.0 at least) is
GPL2-only with a slew of linking exceptions for other licenses
including (very recently) GPL3, but none for AGPL3. My IANAL opinion
is that this would make binary distribution of the program outright
impossible...
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110728014346.gb1...@yuggoth.org
Re: RFS: v3c-2.4.0-01
On 2011-12-16 18:34:22 + (+), Philip Ashmore wrote:
[...]
> I guess I shouldn't post the updates to SourceForge GIT until I
> can get v3c accepted to Debian.
>
> Won't lintian/sponsors complain that the version being submitted
> is newer than the upstream version - the version pointed to by the
> watch file?
Packages officially included in Debian quite often need to be
maintained by different individuals than the upstream software
authors, thus packaging-related work is best managed as a separate
project from the upstream source it packages so that it doesn't get
in the way of those efforts. In Debian source and binary package
file names you'll see the upstream version and Debian package
version are different numbers separated by a hyphen (-). This way,
when only the packaging itself is modified you don't need to
increase the upstream version component since the upstream
tarball(s) remain unchanged from the previous package.
Some pedants will likely bring up native packages as an exception to
this, but in years on this list I don't think I've ever seen a DD
sponsor a native package as new so it's not particularly relevant in
this case.
If your upstream source and Debian packaging are truly separate,
then any changes to your upstream code needed to ease your packaging
work can be committed to your git repository before you start
requesting sponsoring of your Debian source package. That said, if
you have a reasonable need to get a sponsor to upload a package
containing a newer upstream version than the published one (an
embargoed security patch, for example), that shouldn't pose a
problem for a sponsor as long as it's explained sufficiently.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111217025542.gg...@yuggoth.org
