Re: Mandatory LC_ALL=C.UTF-8 during package building
On Thu, Jun 06, 2024 at 07:11:46PM +0200, Michael Biebl wrote: > I would prefer that dpkg-buildpackage provides a "sane" build environment by > default (which I think includes a LC_ setting pointing at a .UTF-8 locale) > and fewer packages explicitly setting those things via debian/rules. same here. like the rest of the world does in 2024. > Afaics, this would actually make efforts like reproducible builds *easier* > as settings provided by reproducible-builds wouldn't be overwritten by > debian/rules. it would make a lot of things easier. :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ No matter how many mistakes you make or how slow you progress, you are still way ahead of everyone who isn't trying. signature.asc Description: PGP signature
Re: Mandatory LC_ALL=C.UTF-8 during package building
On Fri, Jun 07, 2024 at 02:32:14PM +0200, Guillem Jover wrote: > And I think forcing a locale on buildds makes perfect sense, because > we want easy access to build logs. But forcing LC_ALL from the build > tools implies that no tool invoked will get translated messages at > all, and means that users (not just maintainers) might have a harder > time understanding what's going on, we make lots of l10n work rather > pointless, and if no one is running with different locales then l10n > bugs might easily creep in. absolutly agreed & thanks for bringing up this aspect! > Related to this, dpkg-buildpackage 1.20.0 gained a --sanitize-env, > which for now on Debian and derivatives sets LC_COLLATE=C.UTF-8 and > umask=0022. that's great news! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The past is over. signature.asc Description: PGP signature
reproducible Debian containers exists today (Re: Reviving schroot as used by sbuild)
hi, On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote: > I have to ask: > > Could we use a container framework that is also used outside the Debian > bubble, rather than writing our own from first principles every time, and > ending up with a single-maintainer project being load-bearing for Debian > *again*? [...] +1 > Podman uses the same OCI images as Docker, so it can either pull from a > trusted OCI registry, or use images that were built by importing a tarball > generated by e.g. mmdebstrap or sbuild-createchroot. I assume that for > Debian we would want to do the latter, at least initially, to avoid > being forced to either trust an external registry like hub.docker.com > or operate our own. I'd just like to mention the less known fact, that https://docker.debian.net/ provides reproducible images for nine Debian architectures today... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ 🔥 - this is fine. signature.asc Description: PGP signature
Re: Q: Ubuntu PPA induced version ordering mess.
On Mon, Jul 01, 2024 at 05:17:09PM -0700, Russ Allbery wrote:
> I would use an epoch.
yes.
[...]
> Basically, you'd be burning a lot of social capital with upstream for no
> really good reason and you probably still wouldn't be able to convince
> them. I don't think it's worth it.
yes.
> I would just use the epoch. I know people really hate them and they have
> a few weird and annoying properties, but we have a bunch of packages with
> epochs and it's mostly fine.
a bunch?
$ grep ^Version:
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources
|awk ' { print $2 } ' |grep -c :
1142
$ grep -c ^Version:
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources
38200
ok, maybe 3% of all packages is a bunch. :)
> It's something you'll have to keep working
> around forever, but not in a way that's really that hard to deal with,
> IMO.
yes.
> This feels like exactly the type of situation that epochs were designed
> for: upstream was releasing packages with weird version numbers and now
> they're effectively going back to normal version numbers that are much
> smaller. In other words, to quote policy, "situations where the upstream
> version numbering scheme changes." Yes, in this case it was only in their
> packages and not in their software releases, but that still counts when
> they have an existing user base that has those packages installed.
yes.
Thank you Russ, for wording this so well, that I don't have to type much.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
In a world where you can be anything, be kind.
signature.asc
Description: PGP signature
Re: Q: Ubuntu PPA induced version ordering mess.
hi Alec, please stop mailing this thread and just use an epoch. Before adding^wintroducing an epoch one should consult debian-devel@l.d.o, you have done this, arguments were exchanged and (IMNSHO) no better solution was found, so please do what has done to >1000 source packages in the archive already, and add an epoch. Thanks for caring about free software and it's users. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "A fundamentalist gender binary was a key feature of Nazi racial politics and genocide. (...) It must be said that the reality of transgender identity cannot be challenged. Transgender people have existed throughout history." https://www.lemkininstitute.com/statements-new-page/statement-on-the-genocidal-nature-of-the-gender-critical-movement%E2%80%99s-ideology-and-practice signature.asc Description: PGP signature
Re: lintian.debian.org off ?
On Fri, Aug 09, 2024 at 10:32:13PM -0700, Otto Kekäläinen wrote: > Nicolas' implementation (https://lintian.club1.fr/) to list all tags > on one page and link to UDD seems like a reasonable compromise in > functionality and maintenance effort. any DD can point lintian.debian.net to that machine (or anywhere else). -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ There are no jobs on a dead planet. (Also many other things but people mostly seem to care about jobs.) signature.asc Description: PGP signature
Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
On Tue, Aug 20, 2024 at 10:44:30PM -0700, Otto Kekäläinen wrote: > > Advertise widely and frequently that there is a pool of people which is > > happy to help investigating the failed CI jobs. > > Then start personally advocating the benefits of CI to the maintainers > > of these packages: I expect that in most cases you will find out that > > they are not using CI just because they are not well informed about it. > So maybe just send a mass email to the maintainers of these 150 packages? or maybe document it in a more permanent place like developers-reference? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ If you think fertilized eggs are people but parents who've crossed the oceans with their kids aren't, stop pretending your concerns are religious. signature.asc Description: PGP signature
Re: Removing more packages from unstable
Hi, I also like us to remove more broken and unused packages from unstable. On Tue, Aug 20, 2024 at 11:20:10AM +0200, Lucas Nussbaum wrote: > Maybe we could also reduce the cost of removals for users and potential > new maintainers, by improving the information provided in various places > on how to get the latest source and binary packages that were in Debian > (pointing to snapshot.debian.org). > > Things to look at: > - messages sent to the BTS when closing bugs for removed packages > - tracker.debian.org YES, to all of the quoted stuff above. The BTS removal bug for that package should have a pointer to snapshot.d.o with the last sources as well as instructions how to reopen all bugs which were closed by the package removal. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "Climate change" is an euphenism. "Global warming" as well. signature.asc Description: PGP signature
Re: lintian.debian.org off ?
On Wed, Sep 04, 2024 at 08:21:04AM +0200, Lucas Nussbaum wrote: > After lintian.debian.org went unmaintained (beginning of 2022) [...] > After providing stale data for a long time, which confused many people, > lintian.debian.org was shutdown in September 2023. in Debian timeframes, this is basically yesterday and the day before. > At this point, I think it's too late: [...] I disagree: lintian.debian.org was around for more than a decade, so it's still in the minds (and finger memory) of many. On Wed, Sep 04, 2024 at 12:07:39AM -0700, Otto Kekäläinen wrote: > Can we agree to have both UDD and lintian.debian.org, as the work to > develop the required systems already happened? > > I think both websites have their benefits. Having a lintian.debian.org > site with links to man pages and additional information caters well to > the newbie packager or occasional package collaborator. The > lintian.debian.org page can link to the equivalent UDD page, and the > UDD page and continue to list all affected packages. I very much agree with Otto here. & many thanks to everyone who contribut(s|d) to lintian! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The moon landing 50 years ago was paid by taxes, while Bezos space trip was paid by not paying taxes. signature.asc Description: PGP signature
Summary / new quik available (was Re: please test new quik with initrd-support (was: Re: getting quik into sarge?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Peter 'p2' De Schrijver has made some new updates to the quik - you can get it (.deb and source) at the http://www.ulyssis.org/~p2/debjes/ changes include: - manpage tells about initrd - compiles with gcc3 - sprintf bug fixed - ANS raid support quik with initrd has been tested on - - ANS (Peter 'p2' De Schrijver) - - PMac 4400/200 (me) - - PMac 6500/250 (Romain Francoise) - - PMac 7200/90 (Peter 'p2' De Schrijver, me) - - PMac 9500 (Jaakko Niemi) - - PMac Beige G3 Rev II (Simon Vallet) If you got an(other) oldworld machine, please test this quik while installing the latest kernel-image-2.6.8-powerpc.deb (contains an initrd). Nobody mentioned to have tried with less than 32mb ram, if you do, please report your results as well. Colin Watson wrote: > This seems to be inappropriately built as a native package. If it were > built non-native then it would be easier for me to look over the > .diff.gz to see the changes from upstream. Still on the todo list - should be done as fast as possible to be able to achieve the goal of inclusion in sarge.. ;-) regards, Holger -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBsIxXUHLQNqxYNSARApY3AJ992wMaZX5fF7xK0Uly9zvv6JRvhgCfZfhy FUBb29pI2Wc4+msxMRyw8mY= =u/oi -END PGP SIGNATURE-
Re: Summary / new quik available (was Re: please test new quik with initrd-support (was: Re: getting quik into sarge?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Eric,
most cc:s removed - and I'm still thinking wether I should send this as a
private mail... anyway:
I'm sorry if I offended you with my summary mail about the current status of
quik and initrd-support. My aim is to help to get working oldworld support
for d-i (and sarge released ASAP). Since debian sarge defaults to kernel 2.6
on powerpc, initrd-support for quik is almost necessary. Two weeks ago p2 and
myself ("together" with two oldworld boxes ) met at a skolelinux-developer
meeting, where p2 implemented the initrd-code. I just took the task of
telling the world about it ;-)
I you think that me (or maybe p2) knows more about the current status of quik
than you do, feel free to ask. I will gladly answer your questions although I
doubt to know more than you - since all I know I posted in said summary
mails. As far as I know, p2 is "only" interested in fixing quik's code, but
not in maintaining/packaging it.
So, as far as I can see there is nothing to be angry about (anymore?). If you
still got a point, please tell - I don't want make the same mistakes twice.
regards,
Holger
P.S.. Do you need help in packaging a proper quik_2.0e-12.deb (or 2.0f?) ?
This is still needed (ASAP) for the d-i/release people to review the changes
and to be able to decide wether to allow it into sarge or not...
On Friday 03 December 2004 23:49, [EMAIL PROTECTED] wrote:
> Ce jour Fri, 03 Dec 2004, Holger Levsen a dit:
>
> i'd appreciate not having it hijacked from under me. i don't mind
> getting help, and i do appreciate that, but i get the feeling it's being
> hijacked from me. you could at least tell me WTF is going on.
>
> eric
> (the current quik maintainer)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBtGGBUHLQNqxYNSARAolTAJ0eiLNJ8Etgoe6a46fZ4iTu1XNFoACg0XnW
ni/TXodVVCtA7N6tikt+i1I=
=oMJc
-END PGP SIGNATURE-
Re: updated debian development diagram -- comments?
Hi, first I'd like to thank Kevin for his nice diagram! On Wednesday 05 January 2005 20:38, Gunnar Wolf wrote: > Very nice! I expect to use it at some conferences (BTW: Looks like a > nice addition to Debian Eyecatcher[1], I'll add it :) ) but then I also got one concern, especially if this diagram gets used in more or less official debian projects / occasions / whatever (this might be a good place to add that I'm aware that Kevin started that diagram for hisself...) : unstable is described as suited for "...laptops and desktops on non-critical systems..." testing is described as "... can be used for desktop systems that need more stability..." I think this both is wrong. Unstable and testing should not be described as suited for desktops - they are development branches of debian, which are likely to break, which break and... so on. Most of you know :) I'm perfectly aware why some people advocate testing or sid for Desktops (the good ol' "debian releases to seldom" argument...) - but as said I don't think Debian should propagate this misconcepts. regards, Holger
Re: New stable version after Sarge
Hi, On Saturday 08 January 2005 07:45, Christian Perrier wrote: > So, if we imagine we release sarge at February 1st (ahah), just > immediately announce that etch will enter the first freeze stages > (base packages frozen, testing-security checked, d-i frozen) on August > 1st. > > This will give all developers a good idea of the way they can organise > their work. So, even if respecting this schedule may be difficult, we > would probably give us better chances... AOL :-) (Seconded) I wanted to add this to http://wiki.debian.net/index.cgi?ReleaseProposals but as the wiki is read-only at the moment (because migration to a new server) I'll leave this as a reminder for me to try to do it tomorrow... regards, Holger
Re: german debian mirror with 700mb paris.avi file...
Hi, On Monday 31 January 2005 20:36, Martin Schulze wrote: > Anything but a non-public list/forum/whatever would be fine and better. > In fact I have had already informed the admin after a user informed me. > > Since http://www.debian.org/security/ is about the security in Debian > packages technically it would be the wrong place. However, I won't > reject a new item in the FAQ there. I would suggest [EMAIL PROTECTED] - it's a common address to report problems coming from someones network. Obviously this info then has to be put somewhere on the webpages (maybe at http://www.debian.org/contact.de.html#infrastructure ) and some forwarders to "real people" must be established. regards, Holger pgptLTVr8NEcA.pgp Description: PGP signature
good signature... Re: Diversion of APT tools by dpkg-cross (apt-get,apt-cache,apt-config)
Hi, On Wednesday 02 February 2005 10:21, Adrian von Bidder wrote: > > Warning: The signature is bad. > > Something's broken somewhere... > > Can anybody confirm so I can stop worrying about my set up? I cannot confirm this, the signature is valid here. I have no valid trust path to the key, but that's another issue... regards, Holger pgpwQiiQLJP3U.pgp Description: PGP signature
Re: Moin 1.3.x: Status of the package moin
Hi Raphael, you had a typo in Jonas' email address, maybe that's why he didn't answer ? :) regards, Holger On Sunday 13 February 2005 14:04, Raphael Bossek wrote: > Hi Jonas, > > I'm writing you again after my last email was not answered. > I would like to help you out packaging moin 1.3.x. Could you > please contact me on furter development of MoinMoin for Debian? > > If not I will start creating a NMU. > > -- > Raphael Bossek pgpSfG4NtFYEf.pgp Description: PGP signature
etch release plan (was Re: congratulations to our ftp-master team)
Hi, On Thursday 15 December 2005 18:06, A Mennucc wrote: > In my opinion, considering that the release of etch is 15 months away, Please don't consider this :) No matter whether it's a lack of knowledge or disbelieving in the etch release plan (a la "it's scheduled for december so it will become march anyway..."), IMO this contributes a lot to the problems of releasing in time. So I will quote the release plan posted by Steve Langasek on d-d-a two month ago. And as I havent seen an update to this, I assume it's still valid and _doable_. Message-ID: <[EMAIL PROTECTED]> --begin quote [...] This is the timeline that we think will get us there: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We believe that one key to meeting these deadlines is letting maintainers know about them well in advance so that they can plan accordingly, so -- here we are. [...] ---end-quote- If you don't believe your goals are reachable, you won't reach them. (Because then you won't work on reaching them.) Of course those goals also have to be reachable, but I have seen no indication they aren't. regards, Holger pgpmsMFeuYIKw.pgp Description: PGP signature
yet another mass bug filing on GFDL issues ?
Hi,
no, this is not really about the GFDL issue currently discussed, but about
using the unmodified GFDL template in debian/copyright. Besides not being
able to tell who has the copyright, it makes it also impossible to tell if
there are invariant sections and/or cover texts.
Lots of packages (including most of kde, but also gcc-x.y-base, gdb, mtools,
groff-base) are affected.
Do a
find /usr/share/doc -name copyright -exec grep -l "YOUR NAME" {} \;
to find those packages on your system. (This might cause a few false
positives, figlet for example is not affected :)
AIUI, no matter how the outcome of the GFDL GR will be, these are bugs which
needs to be fixed. So to me it smells like another mass bug filing, probably
with user tags.
Hm, on a second thought this (*) _might_ be a feature: the GFDL says invariant
sections need to be listed, but there aren't any, as a template has been
used. Yay ?!
What do you think ?
regards,
Holger
pgpoBtwV4YIxp.pgp
Description: PGP signature
please provide releasenotes (Re: Release update: editorial changes to the testing propagation scripts)
Package: www.debian.org Hi, On Tuesday 03 May 2005 21:46, Steve Langasek posted a fine mail about a fine change (thanks for both to whom it may apply). Whohoo! :-) Regarding testing upgrades from woody, I would like to propose mentioning more visible that the suggested upgrade tool is aptitude, not apt-get - fewer people than you might think read the fine releasenotes :-) This might be related to the fact the they're somewhat hidden, at least to ./google "sarge releasenotes" - http://www.debian.org/releases/testing/releasenotes isn't helpful atm either. regards & keep on rockin' ;-) Holger > As before, being able to hold to this schedule depends heavily on a > steadily dropping RC bug count, so if that isn't happening, the timeline > will have to be tweaked accordingly. > Note once again that you can stage NEW uploads in experimental to avoid > disruption in unstable. pgpxHDe4eT5I4.pgp Description: PGP signature
Re: Bug#307570: please provide releasenotes (Re: Release update: editorial changes to the testing propagation scripts)
Hi Javier, On Wednesday 04 May 2005 13:49, Javier Fernández-Sanguino Peña wrote: > > This might be related to the fact the they're somewhat hidden, at least > > to ./google "sarge releasenotes" - > > http://www.debian.org/releases/testing/releasenotes isn't helpful atm > > either. > Why not? Isn't > http://www.debian.org/releases/testing/i386/release-notes/ch-upgrading.en.h >tml#s-upgradingpackages sufficient? It is. But it wasnt there last night. Someone (thanks!) fixed it today at 01:51:49 Uhr UTC, rougly 30 minutes after my mail ;) I closed the bug now. When I saw this tomorrow morning I was a little bit to find the old browser window from last night still open, showing me, the page was indeed empty last night ;-)) btw, google has no (good) hits for "sarge releasenotes", but for "sarge release notes" they have... maybe this helps. regards, Holger, dropping debian-release from cc: as that list is busy enough today ;-) pgpLOySm6vPbB.pgp Description: PGP signature
Re: Changes to the weekly WNPP posting
Hi, On Thursday 19 May 2005 18:43, Martin Michlmayr wrote: > What do other people think of this? Do you want a shorter WNPP > posting with only new entries on -devel? less frequent, maybe every four weeks ? i've got wnpp-alert in my cron for weekly mails - if people reaaally care, they can put into daily cron, otherwise every four weeks is IMO not really annonying - on d-d-a. maybe even every six to eight weeks... with a pointer to wnpp-alert it should be sufficient. regards, Holger pgpq2w2iZxsk1.pgp Description: PGP signature
Re: Is Ubuntu a debian derivative or is it a fork?
Hi, On Thursday 02 June 2005 07:13, Matt Zimmerman wrote: > If Ian were to approach Ubuntu (rather than, say, Slashdot) with clear and > genuine concerns, I would be more than willing to discuss the situation > with him to explain what we're doing and why. Ian posted this to his blog, not to Slashdot. Either way, dependency hell is not the kind of bright future I like to see ;-) If you agree on this, just keep it in mind and let's work together on avoiding it. regards, Holger pgpPZVr5EGotX.pgp Description: PGP signature
Re: kernel security bug #307900
Hi, On Friday 10 June 2005 04:02, Adam Majer wrote: > > > woody's kernels are vulnerable to CAN-2004-1235, a uselib() race > > condition. > > Will this be fixed for Woody? > > I thought the plan was to provide security support for Woody for > > another year? > AFAIK, there is no security support for Woody kernels for some time now. > Use kernel.org and compile your kernels for security sensitive machines. If this is true, this should be properly documented somewhere. regards, Holger pgpRtFFh6zwaN.pgp Description: PGP signature
Re: Why does Ubuntu have all the ideas?
Hi, On Saturday 29 July 2006 08:43, Christian Perrier wrote: > And get a very nice random theme for gdm, making the system different > each time it's booted up. Very user friendly. I agree with Christian. Quite some people will be confused by this, and it's completly unnecessary to have a random theme as default. (Even if it does look more fancy for those who won't be confused.) regards, Holger pgpYXrirckGOQ.pgp Description: PGP signature
Re: Why no /usr/local/etc in Debian?
severity 383493 serious thanks Hi, On Thursday 17 August 2006 18:45, Kevin B. McCarty wrote: > FYI, I've now filed this as #383493. (Filed as "important" rather than > "serious" to avoid stepping on the toes of release people.) I've learnt that not filing bugs with the appropriate severity does more harm than good. We do want Etch to comply with FHS 2.3, don't we?! :) Note that FHS 2.1 didn't mention /usr/local/etc, while 2.3 does. I'd say this explains why we have this bug today. http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#USRLOCALLOCALHIERARCHY regards, Holger pgpd3VGzzbVKe.pgp Description: PGP signature
Re: so many applications wake up so often
Hi, On Friday 08 September 2006 19:36, John Goerzen wrote: > I have no idea what Gnome, KDE, etc. are doing to my disk -- all I know > is that they seem to have business with it all the time, and it makes it > very difficult for the disk to spin down. do you mount with "noatime" und "nodiratime"? regards, Holger pgp2HivpIEKoL.pgp Description: PGP signature
Re: apt-findremovable v0.1 (initial release)
Hi, On Wednesday 04 October 2006 13:08, Alexey Feldgendler wrote: > Why not just stop using apt-get? aptitude can do everything the same as > apt-get and even supports the same command line parameters. aptitude neither understand "build-dep" nor "source" as command... regards, Holger pgpzOncdKZyob.pgp Description: PGP signature
Re: Bits from the DPL: Looking forward
Hi, On Thursday 05 October 2006 16:12, Junichi Uekawa wrote: > 2007 join as support team to Debconf > 2008 propose Japan as Debconf candidate > 2009 hold Debconf in Japan. This timeline won't work :-) At least the debconf-team hopes so: From 2007 we want to decide the venue two years in advance, that is, during debconf7 we want to decide on the venue for 2009. To make this switch to two years planning possible, we want to decide about debconf8 around the end of this year (2006) or the beginning of the next, see http://lists.debian.org/debian-project/2006/09/msg00137.html regards, Holger pgpH47N7iKIBP.pgp Description: PGP signature
Re: Lack of transparency of automatic actions
Hi, On Friday 13 October 2006 17:18, John Goerzen wrote: > Even worse, you again have to use KDE or Gnome to take advantage of > network-manager. Why are we leaving CLI users out in the cold? It is > quite possible to use mutt, ssh, and ftp on a laptop. And it's > frustrating to know that my network setup will be useless when I'm not > running in X. apt-cache show whereami That added, I agree with most of your post. But that doesn't help :) regards, Holger pgpinvy9I3A5r.pgp Description: PGP signature
Re: How should we deal with 'pointless-on-this-arch' packages?
Hi, On Saturday 14 October 2006 12:51, Wookey wrote: > Nevertheless I think it is clear that we do need mechanisms to keep > the load and package set appropriate for slower arches. If we design > the mechanism properly I would hope it could be useful for various > categorisation/subsetting purposes within debian. Isn't it up to the maintainer to say $package is not suited for $architecture? And aren't maintainers happy to receive hints (e.g. from porters or users of a certain package), which specific package is not suited for a specific architecture? regards, Holger pgpp06gZIloAl.pgp Description: PGP signature
Re: Proposed new POSIX sh policy
Hi, On Monday 06 November 2006 18:07, Russ Allbery wrote: > + required under POSIX, hence this explicit addition. Also, > + rumour has it that this shall be mandated under the LSB > + anyway. I dont think the debian policy should spread rumours about the LSB. Either state facts from the LSB or don't mention it. regards, Holger pgpo7a9q7YngU.pgp Description: PGP signature
Fwd: Re: #397716 - please provide a debian-icon on the default desktop install, not an ubuntu one
severity 397716 serious thanks -- Forwarded Message -- Subject: Re: #397716 - please provide a debian-icon on the default desktop install, not an ubuntu one Date: Friday 10 November 2006 13:52 From: Josselin Mouette <[EMAIL PROTECTED]> To: Holger Levsen <[EMAIL PROTECTED]> Cc: debian-devel@lists.debian.org, debian-desktop@lists.debian.org Le vendredi 10 novembre 2006 à 12:16 +0100, Holger Levsen a écrit : > last weekend I did a etch default debian install, in which gnome is the > default desktop environment. update-manager is installed as a part of it, > and accessable over the Desktop/Administration/update-manager menu. The > icon for the menu shows a cd with an ubuntu-logo, which I think is very bad > marketing for debian. > > P.P.S.: _I_ do think this is somewhat release critical :-D Not only somewhat. According to the Ubuntu trademark policy [1], we have to obtain Ubuntu's approval before using this logo. [1] http://www.ubuntu.com/ubuntu/TrademarkPolicy -- Josselin Mouette/\./\ "Do you have any more insane proposals for me?" --- pgpJLgeibjMc8.pgp Description: PGP signature
#397716 - please provide a debian-icon on the default desktop install, not an ubuntu one
Hi, I filled this as #397716 and have received no reply yet, thats why I bring it up here. Besides the issue brought up in the report it also brings up another interesting question: is there a way to detect if a buildd is building for debian or ubuntu? I can make up a rules file for manual building which chooses the right logo based on an environment variable, but I have no idea how one could do this for autobuilding... package: update-manager version: 0.42.2ubuntu22 severity: important tags: patch Hi, last weekend I did a etch default debian install, in which gnome is the default desktop environment. update-manager is installed as a part of it, and accessable over the Desktop/Administration/update-manager menu. The icon for the menu shows a cd with an ubuntu-logo, which I think is very bad marketing for debian. So I propose to change it (in debian :) to the attached file. The file is located in the source-package at update-manager-$version/data/icons/48x48/software-properties.png regards, Holger P.S.: in case of licence||copyright questions: that file is made by me and based on the original software-properties.png and the debian-logo from www.debian.org. P.P.S.: _I_ do think this is somewhat release critical :-D software-properties.png Description: PNG image pgpJv3aFSGFQj.pgp Description: PGP signature
Re: Bits from the debian-cd team; more CD/DVDs being built regularly
Hi, On Friday 22 December 2006 11:07, Javier Fernández-Sanguino Peña wrote: > I'm not sure if this is done (I assume it's not) but I would really like > the DVDs / CDs to have a 'documentation media' which could be used to read > documentation without having to install the system. I like the idea. Should we file a bug against debian-cd so this doesnt get lost? regards, Holger pgpNWU5aVtlI2.pgp Description: PGP signature
Re: adding ddccontrol to debian
Hi, On Wednesday 31 May 2006 01:08, Roberto C. Sanchez wrote: > The current ITP is not frozen :-) > > I have a package ready at the moment. However, it only cleanly builds > with the version of gcc in Sarge. I have been assured by upstream that > a new release is forthcoming which fixes the build issues with gcc 4.x. > Once it is out, the package will be updated and uploaded. > > -Roberto bcc:ed to the #322774 as that info was not there yet. regards, Holger pgp1J2ZweKVoq.pgp Description: PGP signature
Re: Debconf videos (was: cdrtools)
Hi, On Monday 10 July 2006 10:20, Frans Pop wrote: > > http://meetings-archive.debian.net/pub/debian-meetings/ > But most are still missing there :-( I am painfully aware of this. And I am doing and have been doing what I can do, which is not much (*). There is some light on the horizon now, so expect less crypted information soon. Sorry & regards, Holger (*) technically I could have borrowed a camera and copied >50 tapes to harddisc and cut them again. But as the cutted videos exists on harddrive already I have refrained from doing so so far. pgpX6QQbob3dX.pgp Description: PGP signature
debconf5 - videos of the talks and BOFs available
Hi, "the mighty video team", in boring alphabetical order (but you who where there know who they are), Andrew McMillan, Chris Halls, Erik Johansson, Henning Sprang, Herman Robak, Holger Levsen, Javier Candeira, John Lightsey, Kalle Boess, Martin Langhoff, Noel Koethe, Peter de Schrijver, Tore S Bekkedal is proud to announce the availability of (most of, atm) the videos of the officially scheduled talks and BOFs at debconf5. Jeroen van Wolffelaar and Tuukka Hastrup were not really part of the team, but still deserve special mentioning for their participation... Of course those videos would not have been possible without all the others (...) who made debconf5 the special event it was - it's not completly over as I type this, but almost. Please note, that not all videos are available _now_. The ones missing will be released when they're ready :-) We hope this is soon, but you have take into consideration, that some of us worked >16h a day - so we might need some time to recover. Well, 'nuff said for the moment, dudette, the videos are and will be here: http://dc5video.debian.net regards, Holger pgp5n9joNViqX.pgp Description: PGP signature
Re: Work-needing packages report for Sep 2, 2005
Hi, On Friday 02 September 2005 08:26, [EMAIL PROTECTED] wrote: > The following is a listing of packages for which help has been requested > through the WNPP (Work-Needing and Prospective Packages) system in the > last week. Something is wrong with this list: > The following packages have been orphaned: > >Kate (#325996), orphaned yesterday >Konqueror (#325996), orphaned yesterday >and (#325996), orphaned yesterday >for (#325996), orphaned yesterday >plugins (#325996), orphaned yesterday >text-to-speech (#325996), orphaned yesterday >XMMS (#325995), orphaned yesterday >manager (#325995), orphaned yesterday >playlist (#325995), orphaned yesterday >search (#325995), orphaned yesterday >support (#325995), orphaned yesterday >with (#325995), orphaned yesterday > 176 older packages have been omitted from this listing, see > http://www.debian.org/devel/wnpp/orphaned for a complete list. There text-to-speech (325996) is listed correctly, but qbble (325995) is listed incorrectly as xmms. regards, Holger pgpqXnLi8aK16.pgp Description: PGP signature
Re: a desperate request for licence metadata (was Re: migrating wiki content from twiki (w.d.net) to moinmoin (w.d.org))
Hi, On Tuesday 06 September 2005 01:13, Jon Dowland wrote: > I would like to make a desperate plee that some attempt is made to > incorporate a clear indication of the licence under which material on > this wiki is available under, either with a user-readable prompt or > machine-readable metadata (ideally both). seconded. Actually, the problem is allready there: the content at wiki.debian.net has no licence attached... regards, Holger pgpgo07E60IsC.pgp Description: PGP signature
Re: wiki.debian.net?
Hi, On Monday 26 September 2005 23:39, Peter Samuelson wrote: > Don't know why, but the content is supposed to be moving to > wiki.debian.org real soon now. For moving the contents help is still needed (perl skills prefered), please see http://wiki.debian.org/MigrationStatus regards, Holger pgpEmKqsw8pOt.pgp Description: PGP signature
Re: Bug#331072: ITP: cinelerra-cvs -- non-linear video editor and compositor for Linux.
Hi,
please respect the reply-to: and subscribe to the bugs if you're interested in
solving them... Thanks.
On Saturday 01 October 2005 15:05, Riccardo Setti wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Riccardo Setti <[EMAIL PROTECTED]>
>
>
> * Package name: cinelerra-cvs
> Version : 2.0-cvs
> Upstream Author :
Besides the original upstream (Heroine Virtual Ltd <[EMAIL PROTECTED]>)
the people at http://cvs.cinelerra.org/devcorner/cvswrite.html (or the URL
itself) should be mentioned.
> * URL : http://www.example.org/
This should be changed to http://cvs.cinelerra.org
> This is a branched version of Cinelerra sometimes called
> Cinelerra-CVS
I dont think it's useful (at the moment) to have both versions of cinelerra in
Debian. So #78209, #156614 and #239570 could be closed.
OTOH, it's a seperatly maintained fork, so maybe not. What do you think ?
BTW, IMHO it would really be a good idea to change that name. Maintainers of
cinelerra-cvs, what do you think ? Cinelerra has also been renamed in the
past :-)
On Saturday 01 October 2005 15:44, Sam Hocevar wrote:
>Be careful, more than 1000 Cinelerra source files do not have a
> proper license, a dozen are copyrighted by the MPEG group, another dozen
> are under the old ugly OpenDivX license, and you have many additional
> strange licensing terms in some files (such as free to copy and modify,
> but not to redistribute).
Sam gave me a list with his investigation of the cinelerra-cvs, I have
attached it. What strikes me most, is the lack of licences for 15% of the
whole sourcecode. (1013 out of 6631 (Sam's list from 2004-04-25 / my
cvs-checkout from monday).
Since this investigation is a year old, I would like to ask upstream and the
maintainers of the fork to comment on the current situation. Have those
issues been addressed ? (Yes, i'm too lazy to check this myself now. Thats why
I'm asking the people who should know whether they did that work ;)
>Are you in touch with Holger Levsen <[EMAIL PROTECTED]>? We
> talked about Cinelerra at the QA miniconf and I sent him a list of
> problematic source files I had gathered. He is in touch with other
> people interested in packaging Cinelerra.
I've not really got into touch with the cinelerra-cvs community yet, "only"
with Herman Robak (who is deeply involved in cinelerra-cvs)... With this
mail I try to address the issues and connect the people who could have an
interest in solving them.
http://www.heroinewarrior.com/support.php3 ("real" upstream) mentions the fork
on their support/harrassment page, so I tend to think, they're somewhat happy
about it...
Another big problem: Currently the build requirements for the debian packages
provided from cinelerra-cvs (see
http://cvs.cinelerra.org/getting_cinelerra.html or
http://developer.skolelinux.no/cgi-bin/viewcvs.cgi/*checkout*/external/cinelerra/hvirtual/README.BUILD?rev=HEAD&content-type=text/plain
) include a number of packages which are not in Debian but distributed via
ftp://ftp.nerim.net/debian-marillat/ - I hope that it will be possible to
create a cinelerra version, which works with free codecs from Debian proper
only, and still can use additional codecs from marillat.
I know that this most probably will be a long journey or even impossible - but
if this _is_ impossible I would like to spread the word, so there is an
incentive to work on a truly free tool for editing videos.
Please reply if you want to help on this. If this gets started, we could
create an alioth-project to group-maintain cinelerra-cvs, but for discussing
those details it's currently too early IMHO.
regards,
Holger (subscribed to those bugs and cinelerra-cvs..)
libsndfile/examples/sndfile-play-beos.cpp: GPL
plugins/freeverb/Components/allpass.cpp: public domain
plugins/freeverb/Components/comb.cpp: public domain
plugins/freeverb/Components/revmodel.cpp: public domain
soundtest.c: ???
cinelerra/jdatadst.c: no license
cinelerra/jerrormgr.c: no license
guicast/bootstrap.c: no license
guicast/pngtoh.c: LGPL
libmpeg3/audio/ac3.c: no license
libmpeg3/audio/bit_allocation.c: GPL
libmpeg3/audio/dct.c: GPL
libmpeg3/audio/exponents.c: GPL
libmpeg3/audio/header.c: no license (header file)
libmpeg3/audio/huffman.c: no license (pure data)
libmpeg3/audio/layer1.c: no license (almost empty)
libmpeg3/audio/layer2.c: no license
libmpeg3/audio/layer3.c: no license
libmpeg3/audio/mantissa.c: GPL
libmpeg3/audio/mpeg3audio.c: no license
libmpeg3/audio/pcm.c: no license
libmpeg3/audio/synthesizers.c: no license
libmpeg3/audio/tables.c: no license
libmpeg3/audio/uncouple.c: GPL
libmpeg3/bitstream.c: no license
libmpeg3/libmpeg3.c: no license
libmpeg3/mpeg2qt.c: no license
libmpeg3/mpeg3atrack.c: no license
libmpeg3/mpeg3cat.c: no license
libmpeg3/mpeg3css.c: no licen
changing the default syslog daemon for lenny?
Hi, Debian Edu will be switching its syslog for Lenny and as we want to differ the least possible from Debian, we are wondering, what the default syslog will be in Lenny. The main reason is that we need/want to configure syslogd via debconf (or any other policy complient way) for remote logging and the sysklogd maintainer doesn't want to provide it. See #370339 for details. So we decided to switch to syslog-ng for now. On the #debian-release channel some people claimed, that syslog-ng is not a drop-in replacement, while other said so. I don't know :) Please explain here. Other options would be rsyslog (which Fedora is using, see http://fedoraproject.org/wiki/Releases/FeatureRsyslog) or msyslog. Obviously Debian could also continue to use sysklogd. Oh, and btw, I suggest to change the default for new installations and to keep whatever is installed on upgrades to Lenny. regards, Holger pgpdAnO4xVtvn.pgp Description: PGP signature
Re: table view wnpp page now on wnpp.debian.net
Hi, On Monday 28 January 2008 11:03, Holger Levsen wrote: > Could you add an explaination of "dust" on the page, too? I'm pretty sure > it means "age in days", but as there seem to be 23 wnpp-bugs from today, I > checked half of them as I couldnt believe there are so many on a monday > morning already :) It doesnt mean "age in days" but "days since last activity on the bug". The bugs I checked first, were indeed filed today, but then I saw #456640, which was filed in December but had activity today, so the dust was 0. Also "installs" seems to deserve more explaination. openoffice.org has 859223 installs, which I believe is the installation number of all openoffice.org binary packages reported by popcorn combined. > regards, > Holger pgpJGwUqiafCj.pgp Description: PGP signature
Re: table view wnpp page now on wnpp.debian.net
Hi Sebastian, On Saturday 26 January 2008 02:13, Sebastian Pipping wrote: > thanks to lucas nussbaum the address >http://debian.binera.de/wnpp/ > is now accessible through >http://wnpp.debian.net/ . Heh, cool, I tried wnpp.debian.net last week and it was not there yet :-) Could you add an explaination of "dust" on the page, too? I'm pretty sure it means "age in days", but as there seem to be 23 wnpp-bugs from today, I checked half of them as I couldnt believe there are so many on a monday morning already :) Also, what do the different colors mean? Ah, got that. You could use them as background colors also in the "ITA/ITP = Intent to package/adopt . O = Orphaned . RFA/RFH/RFP = Request for adoption/help/packaging" line. Last, there is no explaination of what the good news and bad news feeds are (or the others). I can guess, but I dont want to have to :-) Besides that, great work! IMO this should be mentioned in the developer news, adding it there. regards, Holger pgp7lPB3bhlAY.pgp Description: PGP signature
Re: changing the default syslog daemon for lenny?
Hi Javier, hi Joey, On Monday 28 January 2008 10:51, Javier Fernandez-Sanguino wrote: > 2008/1/28, Holger Levsen <[EMAIL PROTECTED]>: > > The main reason is that we need/want to configure syslogd via debconf (or > > any other policy complient way) for remote logging and the sysklogd > > maintainer doesn't want to provide it. See #370339 for details. > I find it surprising that the maintainer himself has not pronounced > his standing on the issue. The only reference to the maintainer is a > cut & paste note from an IRC log which might or might not be true. > > The maintainer hasn't even tagged this issue (which is open for almost > 2 years) as 'wontfix'. (!) I agree that this bug should be tagged "wontfix", but I leave it to the maintainer to do it. But I have no reason not to believe the maintainer handles this bug as "wontfix", no (self-written) reply to the bug by him states this pretty well. CC:ed Joey, so he can comment. regards, Holger pgpusFdWv8MHf.pgp Description: PGP signature
Re: changing the default syslog daemon for lenny?
Hi, On Tuesday 29 January 2008 00:55, Russ Allbery wrote: > Of course, since other syslog implementations are potentially better in > larger ways, there may still be good reason to switch the default syslog > to another implementation. It seems to me that everybody replied in favor to this idea and nobody replied suggesting to keep sysklogd the default. Which leads me to believe it should be done :-) I just wonder how... anyone? regards, Holger, who also agrees with http://blog.technologeek.org/2008/01/29/92 pgpucNrUDrp6f.pgp Description: PGP signature
Re: wnpp.debian.net sources released, security review wanted, plans for the future
Hi, On Wednesday 30 January 2008 18:00, Sebastian Pipping wrote: > > What do you think about that lucas? Why only a redirect in the first > > place? > > 1. http://people.debian.org/~nion/net-domains.html > Lucas offered that to me but the host the site runs > on cannot handle a new IP for free. It doesnt need a new IP. Just point wnpp.d.n to the current IP of your server. regards, Holger pgpDlxpIFzkKF.pgp Description: PGP signature
Re: changing the default syslog daemon for lenny?
Hi Michael, On Thursday 31 January 2008 00:11, Michael Biebl wrote: > > - Involve the rsyslog maintainer in the work > I'm here and all ears. I'm willing to work on the necessary steps. > Ok, here we go... I just wish to say a big thanks to you for all the work you've already done on this. You rock! > > - Document the change by preparing a patch for the release notes I guess I c+should at least take over this one ;-) regards, Holger pgpO0pfkOWFUf.pgp Description: PGP signature
Re: dash bug which is affecting release goal
Hi, On Monday 11 February 2008 11:48, Mike Bird wrote: > > > On *production* Debian systems, saving 30 seconds in a boot which > > > may occur once a year for a kernel security update is not worth a > > > single broken script, nor a single failed backup, nor a single lost > > > data bit. > > Since you're talking about *production* systems, “stable” case above, > > so “not a problem”. > Release notes do not offset the millions of person-hours needed to review > and maybe-rewrite and retest the millions of tiny shell scripts that have > been written and tested by millions of Debian users with no thought to the > possible consequences of subsequent changes to /bin/sh. That might be right (or not) but it's irrelevant here. The proposed change is to make dash the default /bin/sh for *new* installations, not to make this change on upgrades from stable etch to stable lenny. And if you bring new servers in production using a new release, without testing for breakage, well... regards, Holger pgpvK4Q042ott.pgp Description: PGP signature
Re: Bug#436267: Firewire support in lenny
Hi, On Tuesday 12 February 2008 12:31, Guus Sliepen wrote: > I do not see why making the old stack available again, but blacklisted > by default, discourages testing of the newer stack. If you have both > available, then yes, users can switch to the new stack more easily, but > at least they will still be using Debian kernel packages, and they can > switch back to the juju stack just as well. If you do not make this > option available, those who have problems with the new stack will have > to compile their own kernels, and then they will not track the Debian > kernel packages anymore. I see this happening all around... (users compiling their own kernels cause they have to and stop tracking debian kernels) Please make the old stack available. regards, Holger pgpqdQ5CrhC1b.pgp Description: PGP signature
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Hi, On Monday 25 February 2008 08:15, Aníbal Monsalve Salazar wrote: > On Mon, Feb 25, 2008 at 09:07:20AM +0200, Lars Wirzenius wrote: > >We had a chicken[¹]. We spent years actively getting rid of it. > >[¹] Technically speaking it was a penguin. But it was a youthful > >penguin, rebelling against its genetic heritage. Oh why? I liked the chicken! When I read Sams mail I immediatly thought of it. Maybe it's good idea to renew the drawing (and keep the basic idea/look), but IMHO thats all. And we should definitly keep the swirl as _the_ logo. > LCA2009 has a tasmanian devil pretending to be penguin [²]. > [²] https://linux.conf.au/ HAHA. Wow, great! regards, Holger pgpVyvyRAI02r.pgp Description: PGP signature
Re: table view wnpp page now on wnpp.debian.net
Hi Tim, On Monday 17 March 2008 10:45, Tim Cutts wrote: > http://wellstyled.com/tools/colorscheme2/index-en.html > > Click on its "triad" button, and it automatically picks three > contrasting colours which work in all forms of colour blindness That page/tool rocks! Thanks for sharing! :) regards, Holger pgpHfd8fi4DQz.pgp Description: PGP signature
Re: table view wnpp page now on wnpp.debian.net
Hi, On Thursday 13 March 2008 23:00, Sebastian Pipping wrote: > Therefore > http://wnpp.debian.net/ > is no longer a HTTP redirect but Great! > Since the page has reached a "stable" state > I would like to ask if there is a chance > to point to it from somewhere on > http://www.debian.org/devel/wnpp/ Which is linked from http://qa.debian.org/ I think normally debian.net sites are not linked from debian.org addresses, except from people.d.o or wiki.d.o, so for now I've added a link to wnpp.debian.net on wiki.debian.org/qa.debian.org. And I'm sending this mail so this can be discussed in the QA team :-) I find wnpp.debian.net much more useful than those lists like http://www.debian.org/devel/wnpp/orphaned ;-) regards, Holger pgpPT06nGI97I.pgp Description: PGP signature
Re: changing the default syslog daemon for lenny?
Hi Michael, (sorry for the bad quoting ratio, but I figured it's nice to bring back the context...) On Thursday 31 January 2008 00:11, Michael Biebl wrote: > rsylogd provides linux-kernel-log-daemon and system-log-daemon, so it > replaces both klogd and sysklogd. The only package depending on klogd is > sysklogd, so there is no problem here. For system-log-daemon I analyzed > the packages depending on it: > > Suggests: > 1.) xwatch: sysklogd > Besides a small example config file, there is nothing syklogd > specific in this package. > Should be changed to $default_syslog |system-log-daemon > 2.) jffnms: syslog-ng > Nothing syslog-ng specific in this package. Should be changed to > $preferred_syslog | system-log-daemon > > Recommends: > 3.) anacron: sysklogd | system-log-daemon > 4.) fcron: sysklogd | system-log-daemon > 5.) heartbeat: sysklogd | syslog-ng | system-log-daemon > 6.) ldirectord: sysklogd | syslog-ng > Should be changed to $preferred_syslog | system-log-daemon > 7.) nullmailer: sysklogd | system-log-daemon > 8.) rlinetd: sysklogd | system-log-daemon > 9.) xinetd: sysklogd | system-log-daemon > > Depends: > 10.) alamin-client: sysklogd | system-log-daemon > 11.) alamin-mysql: sysklogd | system-log-daemon > 12.) alamin-server: sysklogd | system-log-daemon > Uses syslog-facility in postinst/prerm. install will not fail if > syslog-facility is not present. > Easy to use a fixed syslog-facility or even better provide a > rsyslog.d snippet. > 13.) alamin-smpp: sysklogd | system-log-daemon > 14.) fwlogwatch: sysklogd | system-log-daemon > 15.) inetutils-ftpd: inetutils-syslogd | system-log-daemon > 16.) inetutils-inetd: inetutils-syslogd | system-log-daemon > 17.) inetutils-talkd: inetutils-syslogd | system-log-daemon > 18.) inetutils-telnetd: inetutils-syslogd | system-log-daemon > 19.) klogd: sysklogd | system-log-daemon > 20.) logcheck: sysklogd | system-log-daemon | syslog-ng > Has used syslogd-listfiles in postinst, was removed again 2002 > 21.) psad: syslogd | syslog-ng | metalog > Should be changed to $preferred_syslog | system-log-daemon > 22.) request-tracker3.6: sysklogd | system-log-daemon > 23.) snort: sysklogd | system-log-daemon > Has used syslogd-listfiles years again, was removed again > 24.) snort-common: sysklogd | system-log-daemon > 25.) snort-mysql: sysklogd | system-log-daemon > 26.) snort-pgsql: sysklogd | system-log-daemon > 27.) snort-rules-default: sysklogd | system-log-daemon > 28.) sympa: sysklogd (>= 1.3-27) | system-log-daemon > Uses syslog-facility in postrm/postinst to setup a custom facility > to log to /var/log/sympa.log. Doesn't fail to install if > syslog-facility is not found, will log to /var/log/messages > instead. Could easily ship a rsyslog.d snippet. > > So, the only real showstopper is 21.), not having system-log-daemon as > alternative, which makes it uninstallable with rsyslog. > > If there is consensus, I'd go on filing bugs (priority important) > against 1.), 2.), 6.) and 21.), asking for changing the dependency to > rsyslog | system-log-daemon (or if they don't agree with the rsyslog > choice, their preferred system-log-daemon). Did you file those bugs? Is there a usertag for them? > For 12.) and 28.), I'd file a wishlist bug providing a config file > snippet for /etc/rsyslog.d/ > > And finally, if it is approved that rsyslog should be become the default > system-log-daemon, I'd file wishlist bugs against the remaining packages > to change the dependency to rsylog | system-log-daemon, where appropriate. > > > - Involve the rsyslog maintainer in the work > > I'm here and all ears. I'm willing to work on the necessary steps. I'm still willing to help... :) (But as its obvious now, I have lost the status on this..) > > - Document the change by preparing a patch for the release notes > > - Get the priorities fixed by a ftpmaster (assistant) > > Should, I file a lenny release goal first and wait for it's approval, or > can I take this thread as consensus that I can pursue changing the > default system-log-daemon to rsyslog? Or was it already too late for this? regards, Holger pgpPGlnDhapam.pgp Description: PGP signature
Re: changing the default syslog daemon for lenny?
Hi, (Please don't cc: me, I'm subscribed.) On Wednesday 02 April 2008 01:20, Michael Biebl wrote: > Holger Levsen schrieb: > > Did you file those bugs? Is there a usertag for them? > > I tried to collect the information at http://wiki.debian.org/Rsyslog and > started filing the important bugs [1]. Only one bug is open in the usertag list, but most from the wiki are not filed yet. > The real showstopper bug, which > made rsyslog uninstallable, in the psad package, has been fixed already. > For the remaining ones (changing sysklogd | system-log-daemon -> rsyslog > | system-log-daemon), I wanted to wait until rsyslog is actually > accepted as default syslog daemon Makes sense, but also makes this goal a bit look like its stalled. > > I'm still willing to help... :) (But as its obvious now, I have lost the > > status on this..) > If the wiki page is missing information, please let me know. Looks good to me, thanks. > >>> - Document the change by preparing a patch for the release notes > >>> - Get the priorities fixed by a ftpmaster (assistant) > >> Should, I file a lenny release goal first and wait for it's approval, or > >> can I take this thread as consensus that I can pursue changing the > >> default system-log-daemon to rsyslog? > > Or was it already too late for this? > Dunno. We should bring this topic up on debian-release I think to get > more input there. If you want to kick of the discussion, please go ahead. So, hi, debian-release, what is your opinion on this? Do you think we still have the time to do this change for Lenny or is it too late already? regards, Holger > [1] > http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=goal-rsyslog;[EMAIL > PROTECTED] >ebian.org pgpiNad7zzJ40.pgp Description: PGP signature
Re: A suggestion
Hi, On Thursday 03 April 2008 07:19, Anibal Avelar wrote: > Totally I agree. Testing is fine for a personal Desktop machine. I disagree. It's fine for some persons desktops, yes. But it is neither "feature"-supported nor security supported, if users have problems they'll get "use stable if you cant deal with problems" responses. Testing may also broken for an undefined time (because it is a tool for developments and transitions might well be more important than fixing this or that bug). And there are more reasons why testing is called testing. So, IMO, testing is fine for a personal developers desktop. But not in general. regards, Holger pgp0Au1WbJUE5.pgp Description: PGP signature
Re: How to deal with #402010?
Hi, On Friday 04 April 2008 09:18, Cajus Pollmeier wrote: > to virtually any kind of web application accessing some kind of > database/ldap passwords somewhere in the filesystem. I dont consider a web application which is used to configure the LDAP database and FAI configuration (to install and configure all machines in the network) just like any other web application. In this bug are several suggestions how to implement a way better mechanism to deal with the password then the current one. Also I unarchived this bug, because I think the least you can and should do is to document this in the README.Debian. (This=dont allow public html dirs for users and leave safe mode on.) regards, Holger P.S.: regarding those four major ldap servers.. I think it would be a great start if it would be more secure with one of them :-) pgpb3xTTNqVZz.pgp Description: PGP signature
Re: A suggestion
Hi, On Friday 04 April 2008 00:35, Mike Bird wrote: > for sid's xserver-xorg.* 7.3 which has not yet made it to lenny, http://layer-acht.org/debian/xorg-etch-backports/ regards, Holger P.S.: If you wonder why there are no backports on bpo, please provide them. pgp1ZSidIna9I.pgp Description: PGP signature
Bug#474321: Fwd: patch for gpart to support Windows XP NTFS
package: gpart severity: wishlist X-Debbugs-CC: <[EMAIL PROTECTED]>, [EMAIL PROTECTED], debian-devel@lists.debian.org, [EMAIL PROTECTED] -- Forwarded Message -- Subject: patch for gpart to support Windows XP NTFS Date: Friday 04 April 2008 16:33 From: "Trace Green" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], debian-devel@lists.debian.org, [EMAIL PROTECTED] Hello, I hacked gpart, and now gpart v0.1a just support NTFS NT/2000 filesystem, If you use Windows XP, you can not use gpart to try to repair ntfs filesystem. The patch is very simple, and i have tested Windows XP profressional with service pack 2. please test the patch in attachment. --- diff -Nur old/src/gm_ntfs.c new/src/gm_ntfs.c --- old/src/gm_ntfs.c 2008-04-04 22:23:55.0 +0800 +++ new/src/gm_ntfs.c 2008-04-04 22:25:02.0 +0800 @@ -73,9 +73,11 @@ return (1); size = NTFS_GETU64(d->d_sbuf + 0x28); +#if 0 size /= clusterfactor; size *= clustersize; size /= d->d_ssize; +#endif /* * look for an additional backup boot sector at the end of pgphzv4mHl62N.pgp Description: PGP signature
Re: debian-multimedia-keyring/debian-backports-keyring in official debian repository?
Hi, On Monday 07 April 2008 19:57, Peter Jordan wrote: > why are the keyrings of debian-multimedia.org and debian backports not > in the official repository of debian? I guess this was answered already in this thread :-) > At the moment you have to install untrusted keyrings before you can use > these repositories. No need to do this without a trust path at all, it just needs five easy and documented steps to add those keys with a trust path, for the backports archive see: http://wiki.debian.org/DebianEdu/Documentation/Etch/HowTo/Administration#head-136bb7e75e07e8b6463e6b30761ac51776c5c27d That said, I would appreciate debian-backports-archive-keyring package in Debian main, just like there is a debian-edu-archive-keyring. I wouldn't want a debian-multimedia-archive-keyring package in Debian (main), as this archive doesnt promise to comply to the DFSG as the other three archives do. Contrib would probably fine. ITPs anyone? regards, Holger pgpLE4hCmF2dl.pgp Description: PGP signature
Re: [pkg-boost-devel] Bug#473752: Boost 1.35 has been released
Hi Joshua, On Saturday 12 April 2008 03:02, Joshua Judson Rosen wrote: > How close /are/ we to a freeze? Please send a mail to [EMAIL PROTECTED], thanks. Current status of the release: http://lists.debian.org/debian-devel-announce/2008/04/msg2.html Timeline for the release: http://lists.debian.org/debian-devel-announce/2008/02/msg2.html regards, Holger pgpi9UGNmbpSs.pgp Description: PGP signature
Re: Misc development news (#6)
Hi Roberto, On Wednesday 16 April 2008 15:24, Roberto C. Sánchez wrote: > This is something that I propsed on January 3, 2007, on debian-devel. > There was a fairly lengthy thread that resulted and Thomas Viehmann even > offered to help. Of course, he and I both became very busy and so it > sort of fell by the wayside. However, I have my projects much better in > hand this year and I intend to resurrect the idea early this summer. Cool. I've changed the contact address Andreas put there into "Contact: AndreasTille or Roberto C. Sánchez <[EMAIL PROTECTED]> - Roberto intends to work on it..." - feel free to change further :-) regards, Holger pgpl0InoFZ2pn.pgp Description: PGP signature
Re: separate package for iotop?
Hi Paul, thanks for bringing iotop to my attention! On Monday 21 April 2008 13:13, Paul Wise wrote: > Craig, do you think including the iotop python script in procps is a > good idea or should I create a separate package for it. moreutils might also be an option, it would also be a new dependency, but at least it's optional. regards, Holger pgpeAUQRCttzS.pgp Description: PGP signature
Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads
Hi, thanks for starting an initiative to make NMs more useful and accepted! For now I just have two procedural remarks. On Thursday 24 April 2008 21:42, Bas Wijnen wrote: > [0] http://dep.debian.net/deps/dep0/ > [1] http://wiki.debian.org/NmuDep Why isnt the second URL http://dep.debian.net/deps/dep1/ ? :) And secondly, if you had included the actual text in the mail, everybody could reply with proper quoting and I could also read it now. regards, Holger pgpSwWpdtYAA1.pgp Description: PGP signature
Re: SAGE packages for Debian
Hi, wow, great! You're aware that you need to be done in just a bit more than six weeks to achieve your goal of being part of lenny? http://release.debian.org/emails/release-update-200801 regards, Holger pgpanKqExinsP.pgp Description: PGP signature
Re: How to build only linux-image-2.6.18-6-686
Hi Marc, On Saturday 07 June 2008 11:51, Marc Haber wrote: > Shouldn't that be easier to do, Send patches?! ;) > and - most of all - documented? http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage regards, Holger pgprFz3NRVvRf.pgp Description: PGP signature
Re: Automatic debiian installation
Hi Tim, thanks for sharing your experiences. On Wednesday 11 June 2008 12:18, Tim Cutts wrote: > However, FAI usually depends on NFS -- yes, I know about fai-cd -- and > so isn't very appropriate for installing machines which are not part > of the same network (FAI: -1) This isnt really accurate (anymore): first, fai-cd works fine with usbsticks now, too. second, it's trivial to install with d-i (as fai indeed needs nfs for network installation, as you said), and then use fai's softupdate for the rest. I completly use fai without nfs nowadays. regards, Holger pgpXd9c7958Bh.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Hi, On Saturday 21 June 2008 15:52, Alexander Wirt wrote: > I'm still not that sure if its a good idea to add a non-offical debian repo > keyring into the archive... Nobody is forced to install it?! And AFAICS we regulary recommend backports.org to users, who need newer software. So I think it should be in. regards, Holger pgpYuz1oGucxv.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
Hi, while I'm actually in favor of adding this package because it makes it a lot easier to obtain a trustpath to the backports.org repo, which is important to our users, it's not true that there isnt a documented trusted path to install the key. It's documented here: http://wiki.debian.org/DebianEdu/Documentation/Etch/HowTo/Administration#head-136bb7e75e07e8b6463e6b30761ac51776c5c27d # add backports.org repo to /etc/apt/sources.list echo "deb http://www.backports.org/debian etch-backports main contrib non-free" >> /etc/apt/sources.list # install the debian-keyring securily: aptitude install debian-keyring # fetch the backports.org key insecurily: gpg --keyserver pgpkeys.pca.dfn.de --recv-keys 16BA136C # check securily if the key is correct and add it to root's keyring if it is: gpg --keyring /usr/share/keyrings/debian-keyring.gpg --check-sigs 16BA136C && gpg --export 16BA136C | apt-key add - # update the list of available packages: aptitude update But it's really quite complicated and a lot to type :) So I would definitly prefer a package, optionally with a low-priority debconf question (for preseeding mostly) to also edit to sources.list :-) regards, Holger pgpG9VXBUNFlF.pgp Description: PGP signature
Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Saturday 28 June 2008 02:48, Holger Levsen wrote: > It's documented here: > http://wiki.debian.org/DebianEdu/Documentation/Etch/HowTo/Administration#head-136bb7e75e07e8b6463e6b30761ac51776c5c27d now also with the correct order of commands :-) regards, Holger (see, it ain't easy :-D pgpM52lmSyL8W.pgp Description: PGP signature
Re: Bits from Testing Security team
Hi Testing Security team, thanks for the announce-mail and your work! On Wednesday 25 June 2008 11:08, Nico Golde wrote: > General security support for testing > [...] > kernel. Also, we would like to state that packages that are not > security supported for stable are likewise unsupported for > testing. This list includes all packages in contrib and non-free, as > well as the ones that are marked unsupported (for example, > kfreebsd). The maintainers are solely responsible for security and > there won't be any DTSAs for such packages. Where / how are packages marked as unsupported? regards, Holger pgpdRWheLYzoL.pgp Description: PGP signature
Re: Bug#489132: lenny release notes, upgrade dpkg first
Hi, On Thursday 03 July 2008 12:25, Raphael Hertzog wrote: > Given that the new dpkg also supports triggers, we should probably also > recommend to upgrade apt/aptitude at the same time otherwise those tools > might be confused by the new package status... #464559 (in apt) is also a problem for etch to sid/lenny upgrades, so IMHO this is a sensible idea anyway... regards, Holger pgpjzR33N9uk5.pgp Description: PGP signature
Re: piuparts run by every uploader
Hi, On Dienstag, 21. Juli 2009, Jonas Meurer wrote: > is there any chance to get that fixed by either removing the circular > dependency from perl directly or by adding code to manage circular > dependencies to piuparts? as a first approach to this problem I plan to make piuparts ignore circular dependencies from the same source package, which will catch the perl and xorg cases, which have the highest impact on this... patches welcome... regards, Holger signature.asc Description: This is a digitally signed message part.
Bug#506481: please specify more info
tags 506481 -patch +moreinfo retitle 506481 wrong cpu optimisation, please specify more info thanks Hi Mark, as I understand it, this bug report of yours is a bit useless atm, as it specifies a workaround for a non-existing (general) problem, while there is no indication which packages are/were really buggy. Please provide more information about the affcted packages (possible cloning and reassing this bug accordingly), else I'll close this bug in some time. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: Bits from the release team and request for discussion
Hi, On Donnerstag, 30. Juli 2009, Jonathan Wiltshire wrote: > The press team are still announcing [1] this as a "decision to adopt the > policy of timed release freezes beginning with the next release", while > RT maintain that it is under consideration. Which is true? Both! ;-) Or the latter, take your pick. Really, it would have been extremly bad to make a press release the next day reverting yesterdays press release (noone would belive our press releases until after they have aged 48h...) as it would been very bad to just go on... Also, in any case, it's a time based freeze *plan* - how the reality will look when squeeze and squeeze+1 are frozen is not written in PR. And now everybody, fix an RC bug! :) regards, Holger P.S.: Yes, learning is sometimes hard and sometimes its painful too (to learn by mistakes), but in the end, it's definitly worth it. And the alternative is almost always worse. signature.asc Description: This is a digitally signed message part.
piuparts-MBF: not using invoke-rc.d
Hi, as announced at DebConf9 I'll now (slowly) start threads about different bug categories detected by piuparts, with the aim to agree on mass filing bugs with the correct severity. Having a piuparts clean archive is again a release goal for squeeze, currently http://piuparts.debian.org/squeeze/ shows 16198 successfully tested packages, 391 failures and 7800 packages cannot be tested for various reasons: depends which failed the piuparts tests, circular depends so piuparts cannot determine whether the depends have been tested successfully and a bug in piuparts master, preventing some packages to be tested, which could. For today I picked a simple category: packages which have processes running inside the chroot at the end of the piuparts run. This is probably due to directly calling /etc/rc.d/ scripts in packages maintainer scripts, which is a violation of policy 9.3.3.2 and must be replaced by using invoke-rc.d - see http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3. This is mandatory since policy version 3.7.0. http://piuparts.debian.org/squeeze/processes_running_error.html and http://piuparts.debian.org/squeeze/processes_running_error.html lists those packages. Only three packages have been detected which are affected, so I filed bugs with severity serious right away, as IMO this is a pretty clear case of violating a mandatory policy requierement, where the violation seriously disrupts user expectations. Also, filing three bugs is not exactly mass bug filing :-) Other bug categories detected by piuparts will IMO be more worth discussing ;-) regards, Holger P.S.: I've bcc:ed this mail to -qa@ and -release@ and do _not_ plan to continue to do this in the future, unless people ask me to. signature.asc Description: This is a digitally signed message part.
Re: piuparts-MBF: not using invoke-rc.d
Hi KiBi, On Donnerstag, 6. August 2009, Cyril Brulebois wrote: > Holger Levsen (06/08/2009): > > http://piuparts.debian.org/squeeze/processes_running_error.html and > > http://piuparts.debian.org/squeeze/processes_running_error.html lists > > those packages. > Identical URLs? Gah. Forgot to s/squeeze/sid/ in one of them > And for the sake of archiving for one, and for the sake > of people not always online, could you please attach a package list / > dd-list next time? Will try to remember... The three packages of this are zope2.10-sandbox, zope2.10-sandbox and plone3-site. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: piuparts-MBF: not using invoke-rc.d
Hi Roland, On Donnerstag, 6. August 2009, Roland Mas wrote: > Thank you for this effort. I must admit piuparts has been too > frightening for me to try, so far. So, in order to comfort me in my > laziness, would you consider doing continuous (or regular) runs of > piuparts on the whole archive, and sending the results to the PTS Uhm, there was this mail to d-d-a which I planned to send, but haven't, yet ;-) Go to http://piuparts.debian.org where you can find the results for piuparts runs on the whole archive for sid and squeeze (for those packages which have been tested, which are those which depends have been successfully tested by piuparts). These results are already integrated in the PTS, see for example http://packages.qa.debian.org/l/lpr.html - piuparts links are only shown in the PTS if there are problems. Then there are maintainer/uploader specific packages, ie http://piuparts.debian.org/sid/maintainer/l/lolando%40debian.org.html I guess looking at that maintainer page will result in more questions, I hope those are answered on http://wiki.debian.org/piuparts/FAQ - if not, or if you have further questions, please add them there, I'm subscribed to that page and would like to collect questions and answers there, instead of repeating myself endlessly ;-) regards, Holger signature.asc Description: This is a digitally signed message part.
Re: piuparts-MBF: not using invoke-rc.d
Hi, On Donnerstag, 6. August 2009, Holger Levsen wrote: > http://wiki.debian.org/piuparts/FAQ > I'm subscribed to > that page and would like to collect questions and answers there, instead of > repeating myself endlessly ;-) That might leave a wrong impression, so let me add: Thanks for asking here and your interest in piuparts / a clean archive! :-) I'm glad there is interest in this! regards, Holger signature.asc Description: This is a digitally signed message part.
Re: piuparts-MBF: not using invoke-rc.d
Hi Jonas, On Donnerstag, 6. August 2009, Jonas Meurer wrote: > at least for zope2.1[01]-sandbox, i don't know how to fix that issue. > invoking the initscript at postinst/prerm of the -sandbox packages will > cause _all_ zope instances on the system to be restarted, and that isn't > an option at all. > > thus the postinst/prerm scripts of -sandbox packages invoke the zopectl > script at /var/lib/zope2.1[01]/instance/sandbox/bin/zopectl directly in > order to only start/stop the sandbox instance that is being installed or > removed. > > so any ideas what to do about this? fix the zopectl script, so that it can start specific sandboxes and use that from your initscripts? regards, Holger signature.asc Description: This is a digitally signed message part.
piuparts-MBF: overwriting other packages files
Hi, as announced yesterday, I will now continue starting threads about different bug categories detected by piuparts, with the aim to agree on mass filing bugs with a sensible severity. Today I picked another simple category: packages which failed the piuparts test because the package tries to overwrite another packages files without declaring a conflict or replaces relation. See policy 7.4 and 7.6 at http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts and http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces http://piuparts.debian.org/sid/overwrite_other_packages_files_error.html and http://piuparts.debian.org/squeeze/overwrite_other_packages_files_error.html lists those packages. Eleven packages in squeeze and ten in sid are affected. See below for dd-list output. If somebody disagrees that these bugs should be filed with severity serious, speak up now, this weekend I plan to file those bugs. Even though this is IMO again a pretty clear case of violating a mandatory policy requierement, where the violation seriously disrupts user expectations, I havent filed bugs yet, because of ENOTIME :-) regards, Holger Guenter Geiger (Debian/GNU) sox (U) Andrew Lee (æå¥ç§) stardict Daniel Baumann botan-devel tryton-modules-analytic-invoice Mathias Behrle tryton-modules-analytic-invoice (U) Marcus Better ser (U) Wes Chow sparsehash (U) Debian Cyrus SASL Team cyrus-sasl2-heimdal Debian Scientific Computing Team sundials Debian VoIP Team ser Fabian Fagerholm cyrus-sasl2-heimdal (U) Anthony Fok stardict (U) RISKO Gergely libmcrypt Pascal Giard sox Gerber van der Graaf libgpiv GRUB Maintainers grub2 Simon Horman pacemaker (U) Kilian Krause ser (U) Rafael Laboissiere sundials (U) Jordi Mallach grub2 (U) Patrick Matthäi luckybackup Robert Millan grub2 (U) Mark Purcell ser (U) Athena Capital Research sparsehash Anibal Monsalve Salazar gdbm pacemaker Roberto C. Sanchez cyrus-sasl2-heimdal (U) sparsehash (U) Riku Voipio scratchbox2 Jaldhar H. Vyas libcgi-application-plugins-perl Felix Zielcke grub2 (U) signature.asc Description: This is a digitally signed message part.
Re: piuparts-MBF: overwriting other packages files
Hi Manoj, On Freitag, 7. August 2009, Manoj Srivastava wrote: > On Fri, Aug 07 2009, Holger Levsen wrote: > > Today I picked another simple category: packages which failed the > > piuparts test because the package tries to overwrite another packages > > files without declaring a conflict or replaces relation. See policy 7.4 > > and 7.6 at > > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts > > and > > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces I've changed this text now: s/a conflict or/ and also removed the reference to policy 7.4, since conflicts are not enough to prevent the problem of a package trying to overwrite anothers files. > While it is good to discover these bugs, is puiparts the correct > place to do this check? Won't puiparts only report on packages > installed on the machine on which the test is run, and thus miss any > conflicts on packages not currently installed? The piuparts tests on piuparts.d.o are run in clean chroots. http://piuparts.debian.org has more info on the setup. > Also, shouldn't dpkg also complain about installing a package > with conflicts? And thus if one were running puiparts on one's new > package, one would already know about this when one installed the > package on the machine on testing? > > I guess I am somewhat confused. Is this puiparts test telling me > something I would not learn anyway when I install my package for > testing? Not really, especially if you run piuparts yourself before uploading ;) And of course you can also manually do what piuparts does. But not every package is maintained by someone who does this, some packages even don't have a maintainer anymore :-) piuparts(.d.o) is ment as a tool to catch common problems systematically. > Also, wouldn't a periodic check of the Contents.gz files yield > much more exhaustive results? Yes, the results of that are available at http://edos.debian.net/missing-conflicts/ ;-) regards, Holger signature.asc Description: This is a digitally signed message part.
Re: Automatic Debug Packages
Hi, On Sonntag, 9. August 2009, Manoj Srivastava wrote: > The link to the wiki page was missing > http://wiki.debian.org/AutomaticDebugPackages this link was also missing in #508585. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: piuparts-MBF: overwriting other packages files
Hi, On Samstag, 8. August 2009, Manoj Srivastava wrote: > So am I correct in my assumption that only file conflicts with > packages installed on the once-clean chroot would be detected by the > test? Or am I missing something? Yes. for the rest there is edos.debian.net :) > > Yes, the results of that are available at > > http://edos.debian.net/missing-conflicts/ ;-) > Oh, cool, all of these are already reported as bug. Thanks for > the work, whoever is to blame. Ralf Treinen :-) regards, Holger signature.asc Description: This is a digitally signed message part.
Bug#542369: please document how to install suggests
package: apt version: 0.7.22.2 x-debbugs-cc: debian-devel@lists.debian.org severity: wishlist On Mittwoch, 19. August 2009, Eugene V. Lyubimkin wrote: > Andreas Tille wrote: > > I even failed to grep "man apt-get" for the string "suggests" so > > I think I can not do something like > >apt-get --include-suggest install > > -o 'Apt::Install-Suggests=1' please document this in the apt-get manpage. Thanks, Holger signature.asc Description: This is a digitally signed message part.
piuparts-MBF: prompting due to modified conffiles which where not modified by the user
Hi, for some packages the piuparts upgrade test failed because dpkg detected a conffile as being modified and then prompted the user for an action. As there is no user input, this fails. But this is not the real problem, the real problem is that this prompt shows up in the first place, as there was nobody modifying this conffile at all, the package has just been installed and upgraded... This is a violation of policy 10.7.3, see http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3, which says "[These scripts handling conffiles] must not ask unnecessary questions (particularly during upgrades), and must otherwise be good citizens." Affected packages are: cdd-dev_0.6.3 cherokee_0.99.20-1 conntrackd_1:0.9.12-1 junior-config_1.15 med-config_1.2 openswan_1:2.6.22+dfsg-1.1 science-config_0.6 The logs are linked from http://piuparts.debian.org/squeeze/conffile_prompt_error.html I'm a bit uncertain with what severity to file these bugs, OTOH it's quite harmless, OTOH this is clearly a violation of a must-requierement in policy and whats more important, it confuses the user (who likely will manually try to find the changes) and makes upgrading more painful. Opinions on the severity to file these bugs? In any case those bugs should really really be fixed for squeeze :-) regards, Holger signature.asc Description: This is a digitally signed message part.
Re: piuparts-MBF: prompting due to modified conffiles which where not modified by the user
Hi, On Mittwoch, 19. August 2009, Steve Langasek wrote: > On Wed, Aug 19, 2009 at 12:15:04PM +0200, Holger Levsen wrote: > > The logs are linked from > > http://piuparts.debian.org/squeeze/conffile_prompt_error.html > Not harmless at all. These are serious bugs. I'll file those accordingly :-) regards, Holger signature.asc Description: This is a digitally signed message part.
Re: State of developers-reference
Hi, On Mittwoch, 9. September 2009, Jon Dowland wrote: > If this was a popular choice (which it doesn't appear to > be); it would be blocked on sorting out the wiki.d.o > content licensing. No. http://wiki.debian.org/DebianEdu/Documentation/Lenny has a very fine and sosorted licence situation. All GPL-2+ :) regards, Holger signature.asc Description: This is a digitally signed message part.
who should cleanup /var/lib/update-rd.d ? should it be cleaned up at all?
Hi, today I noticed that quite many packages fail the piuparts test, because of a file left after purge in /var/lib/update-rd.d - who's responsibility is it to clean this up? Each package? Or? Or shouldn't those be cleaned on purge and piuparts should ignore those files? (I don't think the latter is the correct approach.) http://paste.debian.net/46146/ shows affected logs in sid. regards, Holger signature.asc Description: This is a digitally signed message part.
Bug#545949: who should cleanup /var/lib/update-rd.d ? should it be cleaned up at all?
package: sysv-rc severity: important x-debbugs-cc: debian-devel@lists.debian.org User: debian...@lists.debian.org Usertags: piuparts piuparts.d.o Hi Petter, On Mittwoch, 9. September 2009, Petter Reinholdtsen wrote: > > today I noticed that quite many packages fail the piuparts test, > > because of a file left after purge in /var/lib/update-rd.d - who's > > responsibility is it to clean this up? Each package? Or? Or > > shouldn't those be cleaned on purge and piuparts should ignore those > > files? (I don't think the latter is the correct approach.) > > The directory belong to the sysv-rc package, and will be cleaned up > when that package is removed. :) > > We discussed on IRC to remove files from there when update-rc.d is > asked to remove symlinks to a script, and if we decide to implement it > that would solve the piuparts issue. Thanks for bringing it to our > attention. :) Thanks for your reply, filing a bug so this doesnt get forgotten. regards, Holger signature.asc Description: This is a digitally signed message part.
#545996: please inform submitters they need to subs cribe
package: bugs.debian.org severity: wishlist x-debbugs-cc: debian-devel@lists.debian.org Hi, On Donnerstag, 10. September 2009, Bernhard R. Link wrote: > But reporters are sacrifing some of their time to help us make our > distribution better. Do you really think we should scare them away > by rewarding bug reports by pulling the reporters in lengthy > discussions how the bug is best fixed? I think I agree with this rhetorical question. But I also think the acknowledgement mail should contain the information that the submitter is not being subscribed by default and how s/he can subscribe. Also it would be nice if #351856 would be implemented, so people who want this, will be automatically subscribed to their bugs. regards, Holger P.S.: this mail was manually resend to -devel, somehow my mail triggered a bug in the BTS, so instead of this mail being send with the bugnumber to -devel@ (as it usually works), this time I got a confirmation request for my subscription to debian-bugs-dist-requ...@lists.debian.org 8-) P.S.: After three attempts I gave up and went to the listmaster irc channel where I learned that my mail didnt make it through because I had "subscribe" in the subject... signature.asc Description: This is a digitally signed message part.
Re: Bug#545949: who should cleanup /var/lib/update-rd.d ? should it be cleaned up at all?
Hi, I've just rescheduled piuparts testing for 233 failed packages in sid which were affected by #545949, which has been fixed now - thanks for that. No packages in squeeze were affected. regards, Holger signature.asc Description: This is a digitally signed message part.
/var/www is depracated, which directory to use?
Hi, currently munin ships some file(s) in /var/www/munin/ and also puts its generated graphs there. This location has been depracted and we, the munin maintainers, would like to come up with a new location for squeeze. The way I read http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM /srv/munin would be the proper location for our purpose, but I know that some people disagree, claiming that /srv is only to be used by the local admins. As I read it, no package should remove files there, but placing files there should be fine. What's more important, I don't see which location is better suited. http://lintian.debian.org/tags/dir-or-file-in-var-www.html nor debian-policy is helpful to resolve this issue - so I would like to discuss this here and come up with a good solution. Suggestions? regards, Holger signature.asc Description: This is a digitally signed message part.
Re: /var/www is depracated, which directory to use?
Hi Sean, On Sonntag, 27. September 2009, sean finney wrote: > > > currently munin ships some file(s) in /var/www/munin/ and also puts its > > > generated graphs there. This location has been depracted and we, the > > > munin maintainers, would like to come up with a new location for > > > squeeze. > take a look at http://webapps-common.alioth.debian.org/draft/html/ , which > covers most of the stuff you're asking about. I've skimmed it and neither 3.1 nor 5.1.1 covers what I'm interested at. Where to put static files is easy... but not my main question :) > i would recommend similar, but with the modification that you use a > dedicated subdirectory (i.e. /usr/share/munin/site), so that you still > have /usr/share/munin for other uses as well. Thats for read-only data only. > > I personally do not believe that serving anything from a package via the > > web by default is a good goal. Certainly for my systems, any system > > that's running a web server has a virtual host configuration and anything > > that packages try to do to control what my web server serves out is > > broken and undesireable. > i'd have to disagree there. i think anything that might serve up content > while unconfigured is a horrible idea I think having munin working out-of-the-box is a very neat feature. > (one more reason to avoid /var/www > and /usr/lib/cgi-bin), but if someone installs an application that can > behave sanely out of the box, i don't see why one shouldn't go out of > their way to do so. munin can. I just dont know where to go ;-) regards, Holger signature.asc Description: This is a digitally signed message part.
Re: different .diff.gz for different platforms (armel) prohibiting upload
Hi, On Montag, 28. September 2009, Rene Engelhard wrote: > > That said uploading missing binaries yourself is not the rigt way > > forward, official build daemons must be able to build it and you should > > work with buildd maintainers and porters to get your package built (and > > building). > If they listened or cared about problems, and not just ignore them, yes... Uhm, no. regards, Holger, looking forward to the day the archive will _only_ accept source-only uploads (or throw away the binaries...) signature.asc Description: This is a digitally signed message part.
Re: /var/www is depracated, which directory to use?
Hi, On Montag, 28. September 2009, Tollef Fog Heen wrote: > I realise you've had good an constructive responses for webapps, so > commenting on /srv in particular: > > As I read it, putting stuff there is absolutely not fine. Where do you read this? http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1192 explicitly says: "This is particularly important as these areas will often contain both files initially installed by the distributor, and those added by the administrator." which to me very much sounds like the distributor (=Debian here) can place directories there... regards, Holger signature.asc Description: This is a digitally signed message part.
Re: different .diff.gz for different platforms (armel) prohibiting upload
Hi, On Montag, 28. September 2009, Rene Engelhard wrote: > I just said that there are buildd admins/porters who are hard to deal > with because they just don't care about build failures not caused by > the package to be built and neither with any package else but by > buildd/machine/arch issues. [...] > At which time it'll get even more funny when buildds don't try to > build stuff - and yes, even security buildds. You really believe > a DSA is possible nowadays without uploading handbuilt binaries? Then > you haven't seen reality. Well, I think this reality sucks and should be fixed. Uploading manually build security packages is a workaround which is error prone, as could be seen in the last months, where there were several uploads done in wrong build environments. If there are really such non-caring buildd admins/porters this should be fixed at the root of the problem and not by using a workaround, which introduces new problems and doesnt touch the root at all. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: different .diff.gz for different platforms (armel) prohibiting upload
On Sonntag, 4. Oktober 2009, Julien Cristau wrote: > > Well, I think this reality sucks and should be fixed. > Hahaha. Good luck with that plan :) I find your lack of faith disturbing. signature.asc Description: This is a digitally signed message part.
Bug#544590: moreinfo
tags 544590 + moreinfo thanks Hi Praveen, what graphics card do you have and which driver do you use? (please post the output of "lspci -n" and "dpkg -l|grep xserver-xorg-video") can you try kernel 2.6.30 and see if the problem is still there? thanks, Holger signature.asc Description: This is a digitally signed message part.
Re: Bug#551123: ITP: echinus -- lightweight tiling window manager
Hi, On Freitag, 16. Oktober 2009, Francesco P. Lovergine wrote: > Most tiling WM are customizable by changing one configuration file. > On that regardi, dwm is quite unique. So you're arguing that echinus fixes this bug in dwm and echinus should conflict+provide dwm? ;-) regards, Holger signature.asc Description: This is a digitally signed message part.
