Bug#547492: ITP: python-junitxml
package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org
A tiny junit extension.
Source: pyjunitxml
Section: python
Priority: optional
Maintainer: Robert Collins
Build-Depends: debhelper (>= 5.0.38), cdbs (>= 0.4.49),
python-all-dev (>= 2.3.5-11)
Build-Depends-Indep: python-docutils, python-support (>= 0.5.3)
Standards-Version: 3.8.3
Package: python-junitxml
Architecture: all
Depends: ${python:Depends}, ${misc:Depends}
Description: PyUnit extension for reporting in JUnit compatible XML
A PyUnit extension to output JUnit compatible XML.
signature.asc
Description: This is a digitally signed message part
Bug#547531: ITP: blahtexml -- Converts TeX equations into MathML
Package: wnpp Severity: wishlist Owner: Abhishek Dasgupta * Package name: blahtexml Version : 0.7 Upstream Author : Gilles Van Assche , David Harvey * URL : http://gva.noekeon.org/blahtexml/ * License : BSD, CC-BY (documentation) Programming Lang: C++ Description : Converts TeX equations into MathML Blahtex converts an equation given in a syntax close to TeX into MathML. Blahtexml is a simple extension of blahtex. In addition to the functionality of blahtex, blahtexml has XML processing in mind and is able to process a whole XML document into another XML document. Instead of converting only one formula at a time, blahtexml can convert all the formulas of the given XML file into MathML. -- System Information: Debian Release: 5.0 APT prefers jaunty-updates APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 'jaunty') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile (was: Packages that download/install unsecured files)
On Sat, 19 Sep 2009 15:52:17 + (UTC), Philipp Kern wrote: >On 2009-09-19, Marc Haber wrote: >> On Fri, 18 Sep 2009 15:56:07 + (UTC), Philipp Kern >> wrote: >>>On 2009-09-18, Tom Feiner wrote: Looks like this method works well for clamav-data and other similar packages which needs to update databases frequently on stable/oldstable. >>>clamav-data is scheduled for deletion as soon as volatile moves onto >>>ftp-master, so that's no precedent. (I.e. there is opposition against >>>daily builds entering the archive without real developers signing them.) >> Why does the person responsible for these uploads not know about this >> opposition? Why was the person doing the significant work not informed >> about the fact that every single minute put into the package is wasted >> anyway? > >If I recall the channel discussion correctly you were present and aware of >the discontinuation. Maybe I recall it incorretly, though. Das muss ich verdrängt haben. I still get absolutely furious about this "decision" when I think about it, so I'd better not think about it. Thanks for the reminder. I'm going to kill off clamav-data the second the build process breaks for the next time. It's really a shame to see weeks of work going down the drain due to political restrictions. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
Marc Haber wrote: > On Sat, 19 Sep 2009 15:52:17 + (UTC), Philipp Kern > wrote: >> On 2009-09-19, Marc Haber wrote: >>> On Fri, 18 Sep 2009 15:56:07 + (UTC), Philipp Kern >>> wrote: On 2009-09-18, Tom Feiner wrote: > Looks like this method works well for clamav-data and other similar > packages > which needs to update databases frequently on stable/oldstable. clamav-data is scheduled for deletion as soon as volatile moves onto ftp-master, so that's no precedent. (I.e. there is opposition against daily builds entering the archive without real developers signing them.) >>> Why does the person responsible for these uploads not know about this >>> opposition? Why was the person doing the significant work not informed >>> about the fact that every single minute put into the package is wasted >>> anyway? >> If I recall the channel discussion correctly you were present and aware of >> the discontinuation. Maybe I recall it incorretly, though. > > Das muss ich verdrängt haben. I still get absolutely furious about > this "decision" when I think about it, so I'd better not think about > it. > > Thanks for the reminder. I'm going to kill off clamav-data the second > the build process breaks for the next time. It's really a shame to see > weeks of work going down the drain due to political restrictions. Hmm, nothing is black and white. The current way of uploading clamav-data is suboptimal and ftpmasters don't want that to continue when volatile is integrated in the main archive. Though that does not mean there are no alternatives. Back then you did not seem interested in any alternative way of doing it and rather discontinue the service completely. Is this still true or should we start thinking of alternatives? Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
2009/9/19 Eugene V. Lyubimkin :
> Anton Piatek wrote:
>>> This should really be done by the package management, not by the user.
>>
>> It sounds like you are describing the following:
$stable: package foo
>> manually installed
$stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts
foo}
>> foo should now be marked as removeable, bar should be marked as
>> manually installed (i.e. take the state associated with foo)
>>
>> Can any of that be achieved with postinst scripts?
> That's a very bad idea IMO.
Care to elaborate?
Anton
--
Anton Piatek
email: an...@piatek.co.uk
blog/photos:http://www.strangeparty.com
pgp: [0xB307BAEF] (http://www.strangeparty.com/anton.asc)
fingerprint: 116A 5F01 1E5F 1ADE 78C6 EDB3 B9B6 E622 B307 BAEF
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Transitional (dummy) packages considered silly
Anton Piatek wrote:
> 2009/9/19 Eugene V. Lyubimkin :
>> Anton Piatek wrote:
This should really be done by the package management, not by the user.
>>> It sounds like you are describing the following:
> $stable: package foo
>>> manually installed
> $stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts
> foo}
>>> foo should now be marked as removeable, bar should be marked as
>>> manually installed (i.e. take the state associated with foo)
>>>
>>> Can any of that be achieved with postinst scripts?
>> That's a very bad idea IMO.
>
> Care to elaborate?
Doing that would:
1) interfere with a package manager (un)setting 'autoinstalled' status
2) require a big script snippet with uncertain logic and a number of guessings
Dealing with 'autoinstalled' property is a deal of a package manager only.
Trying to interfering will introduce the mess.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
Re: Transitional (dummy) packages considered silly
On lördagen den 19 september 2009, Pierre Habouzit wrote:
> On Thu, Sep 17, 2009 at 11:52:23PM +0200, Magnus Holmgren wrote:
> > When a binary package is renamed or split, as well as if several packages
> > are merged under a new name, transitional packages are normally created,
> > which depend on the new packages, which in turn Replaces and Conflicts
> > with, and possibly Provides, the old packages. I find those dummy
> > packages as silly to create as to uninstall after upgrading.
> >
> > I propose a new control field called e.g. Supersedes that will provide
> > the same semantics. In its simplest form, a renamed package will declare
> > that it Supersedes the old package name. That will be considered
> > equivalent to conflicting with/replacing earlier versions of the
> > superseded package, as well as providing a new version of it, just like a
> > dummy package. Multiple packages can supersede the same package (but they
> > should probably be the same version), and one package can of course
> > supersede many others.
>
> Well, I'm not sure what the practical gain is, could you please
> elaborate on the suggested Supersedes: semantics ?
>
> Note that transitional packages are seamless for users. When users has
> foo in $stable, and foo gets renamed into bar in $stable +1, then there
> is that:
>
> $stable: package foo
> $stable + 1: foo Depends bar, bar {replaces foo, provides foo, conflicts
> foo} $stable + 2: foo is dropped, replaces/provides/conflicts foo in bar
> can be dropped.
>
> After user has upgraded from $stable to $stable + 1, he doesn't have
> 'foo' anymore.
He still has the transitional package 'foo' until he decides to go looking for
transitional packages and removes it (after clearing the 'autoinstalled' flag
on 'bar'). If he doesn't do that before upgrading to $stable+2, there's a
chance that there is a different package 'foo' that 'foo' will be "upgraded"
to.
> There is one point in having the transitional package: it ensures that
> no package does try to take "foo" as a package name in $stable + 1 which
> would then in turn confuse apt.
A transitional package doesn't strictly prevent a maintainer from uploading
another source package with a binary package that takes the place of the
transitional package, as long as the version of the new package is greater,
which it has to be even if the old package only exists in stable, doesn't it?
> That is the state of the art. Could you please elaborate where and why
> this field would help ?
>
> FWIW I would be interested to read about a field semantics that would
> solve the git issue properly.
>
> IOW in lenny we have git being the GNU file manager stuff, and git-core
> the VCS. If you find a scheme that would allow git-core to become git,
> and git to become gnuit in _one_ release cycle[1] then your proposal is
> worth it.
Let me elaborate on my last paragraph. The idea is that if 'bar' Supersedes
'foo', then versions of 'foo' greater than that of 'bar' (or an explicitly
declared version) are a different package and should not be considered for
upgrading 'foo'. For example:
lenny:
git 4.3.20-10
git-core 1:1.5.6.5-3+lenny2
squeeze:
gnuit 4.9.5-1
Supersedes: git (4.9.2-1)
git 1:1.6.4.3-2
Supersedes: git-core (1:1.6.4.3-2)
On upgrade, since gnuit supersedes git at version 4.9.2-1 (the first version
with the new name), it "cuts off" the path to git 1:1.6.4.3-2. So if you had
git you get gnuit, and if you had git-core you get git. Note that if you
explicitly ask for just git 1:1.6.4.3-2 when you have git 4.3.20-10, instead
of upgrading, you won't automatically get gnuit unless extra intelligence is
implemented.
> Finally, I think your proposal doesn't work, because "Supersedes" cannot
> work if two distinct binary packages "Supersedes" the same binary. We
> can obviously ensure this doesn't happen in the _same_ Debian
> distribution. I don't see how we can feasibly ensure it across different
> releases in a sane way (and I know lots of people having deb lines for
> stable, testing and sid in their sources.list).
If two packages supersede the same package 'foo', then both should be
installed in place of 'foo' on upgrade, but only if they supersede the same
version of it (I suppose that's how it will have to be done). So you can have
e.g. (modulo syntactic details) foo 1.3.7-3, bar 1.3.7-4 (Supersedes: foo
(1.3.7-4), a new foo 1:1.0.2-1, then later a foo-bar 1:1.2.0-3 that Supersedes
foo (1:1.2.0-3), and it will be possible to deduce that foo 1.3.7-3 should be
upgraded to bar 1.3.7-4 and not to foo-bar.
Multiple different packages reusing the same name in subsequent releases seems
pretty contrived to me, however.
> All in all, I think your proposal is just a shorthand to make your
> debian/control marginally smaller and having to write extensive
> (slow[2]) patches to dpkg, but also britney, dak and pretty much
> everything dealing with .debs, for absolutely no real gain wrt
Re: opposition against clamav-data in debian volatile
On Sun, 20 Sep 2009 17:10:45 +0200, Luk Claes wrote: >Hmm, nothing is black and white. The current way of uploading >clamav-data is suboptimal and ftpmasters don't want that to continue >when volatile is integrated in the main archive. Though that does not >mean there are no alternatives. Back then you did not seem interested in >any alternative way of doing it and rather discontinue the service >completely. Is this still true or should we start thinking of alternatives? As long as you do not expect me to manually sign every single upload, I'm fine with alternatives. Back when Andreas was in charge, he said that he'd prefer the packages to be unsigned instead of being automatically signed with a passphaseless key. I am fine with reducing the upload frequency (and would, in that case, continue to provide more frequently built packages on people.d.o), but I am not fine with regular manual work being required. I am also fine with more paranoia before the upload, for example, to have kind of a "master" package on a trusted system which would be debdiffed against a newly built package to catch differences in the file list. It would be massively easier if I knew what are the real issues instead of sending someone saying in IRC "ftpmaster doesn't want clamav-data any more, please ready yourself to see your work going down the drain" but doesn't know any more. That being said, it looks like volatile's policies are going to change BIG TIME when it gets integrated into the main archive, and frankly, as a volatile user, I'd rather see volatile stay separate than seeing some of its previous principles dumped. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Quick analysis of the Python dist-packages transition
On Fri, Sep 18, 2009 at 09:18:16PM +0200, Josselin Mouette wrote: > * 505 of these packages do not use distutils and should not be > affected, still shipping files to site-packages/. However, > according to Scott Kimmermann (who handled parts of this > transition in Ubuntu), python-central does not look for modules > in /usr/lib/python2.6/site-packages, so most modules using it > are broken. What do you mean, "look for" modules there? Are you proposing that these packages ship files under /usr/lib/python2.6/site-packages, or that python-central find modules under this directory at build-time and move them to /usr/lib/python2.6/dist-packages? AIUI, the former would be contrary to upstream's wishes regarding the organization of distro-provided modules. > If this is the case, python-central needs to be NMUed to handle > such packages. There is no bug filed against python-central for this. An NMU would be out of order. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Quick analysis of the Python dist-packages transition
[Steve Langasek, 2009-09-20] > On Fri, Sep 18, 2009 at 09:18:16PM +0200, Josselin Mouette wrote: > > * 505 of these packages do not use distutils and should not be > > affected, still shipping files to site-packages/. However, > > according to Scott Kimmermann (who handled parts of this > > transition in Ubuntu), python-central does not look for modules > > in /usr/lib/python2.6/site-packages, so most modules using it > > are broken. > > What do you mean, "look for" modules there? Are you proposing that these > packages ship files under /usr/lib/python2.6/site-packages, or that > python-central find modules under this directory at build-time and move them > to /usr/lib/python2.6/dist-packages? no, move them to /usr/share/pyshared, just like it does with dist-packages > There is no bug filed against python-central for this. I will file a bug in a minute (not that it will change much) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: libjpeg62-dev -> libjpeg-dev transition
On Sat, Sep 19, 2009 at 03:00:54PM -0700, Steve Langasek wrote: > On Sat, Sep 19, 2009 at 07:40:28PM +0200, Pierre Habouzit wrote: > > On Sat, Sep 19, 2009 at 07:20:40PM +0200, Pierre Habouzit wrote: > > > On Sat, Sep 19, 2009 at 02:32:51PM +0200, Andreas Barth wrote: > > > > * Pierre Habouzit (madco...@madism.org) [090919 01:08]: > > > > > I'll put blocks in my hint file to be sure that both those packages > > > > > will > > > > > migrate in testing together (I'm unsure if britney is clever enough to > > > > > block them until all the binNMUs are done, I don't think it is). Then > > > > > please ask for binNMUs of all the package that B-D on libjpeg-dev. > > > > > Then > > > > > we will let that migrate. > > > > > The question is: Are libjpeg62 and libjepg7 co-useable? (This only > > > > works if symbol versioning is turned on.) > > > > Huh, libjpeg62 and libjpet7 have different so-name so they are > > > co-installable. I don't get what you mean with "co-useable" and it > > > certainly has nothing to do with symbol versioning. > > > If you meant things built against libjpeg7 and loading plugins linked > > against the libjpeg62 then yes, I think we're good, because libjpeg7 > > uses symbol versioning. libjpeg62 doesn't though. > > Then they're not usable together under any circumstances where libjpeg7 will > be loaded into memory first. Hmm, you're right. So we need an intermediate upload before the virtual package changes where libjpeg7 Breaks libjpeg62. Bill could you do that please ? Then we'll proceed with switching the -dev Provides, blocking libjpeg62 from tansitionning, and launching the binNMUs of anything that build-depends upon libjpeg-dev. Then we'll see what becomes uninstallable because of the breaks, and fix those packages first. Then let that migrate. Bill, could you also check if any of the packages that already Build-Depend on libjpeg-dev will FTBFS ? Those packages have to be fixed before we start the binNMU campaign, so that no _known_ issue impedes us. We'll already have our load of unexpected ones... TIA. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org signature.asc Description: Digital signature
Re: Transitional (dummy) packages considered silly
On Sun, Sep 20, 2009 at 06:16:52PM +0200, Magnus Holmgren wrote: > On lördagen den 19 september 2009, Pierre Habouzit wrote: > > There is one point in having the transitional package: it ensures that > > no package does try to take "foo" as a package name in $stable + 1 which > > would then in turn confuse apt. > > A transitional package doesn't strictly prevent a maintainer from uploading > another source package with a binary package that takes the place of the > transitional package, as long as the version of the new package is greater, > which it has to be even if the old package only exists in stable, doesn't it? I think either britney or dak should choke on that at some point. > > That is the state of the art. Could you please elaborate where and why > > this field would help ? > > > > FWIW I would be interested to read about a field semantics that would > > solve the git issue properly. > > > > IOW in lenny we have git being the GNU file manager stuff, and git-core > > the VCS. If you find a scheme that would allow git-core to become git, > > and git to become gnuit in _one_ release cycle[1] then your proposal is > > worth it. > > Let me elaborate on my last paragraph. The idea is that if 'bar' Supersedes > 'foo', then versions of 'foo' greater than that of 'bar' (or an explicitly > declared version) are a different package and should not be considered for > upgrading 'foo'. For example: Actually Supersedes should always be versionned I think, which is something I missed, and make the thing pretty interesting in fact ... > > Finally, I think your proposal doesn't work, because "Supersedes" cannot > > work if two distinct binary packages "Supersedes" the same binary. We > > can obviously ensure this doesn't happen in the _same_ Debian > > distribution. I don't see how we can feasibly ensure it across different > > releases in a sane way (and I know lots of people having deb lines for > > stable, testing and sid in their sources.list). > > If two packages supersede the same package 'foo', then both should be > installed in place of 'foo' on upgrade, but only if they supersede the same > version of it (I suppose that's how it will have to be done). So you can have > e.g. (modulo syntactic details) foo 1.3.7-3, bar 1.3.7-4 (Supersedes: foo > (1.3.7-4), a new foo 1:1.0.2-1, then later a foo-bar 1:1.2.0-3 that > Supersedes > foo (1:1.2.0-3), and it will be possible to deduce that foo 1.3.7-3 should be > upgraded to bar 1.3.7-4 and not to foo-bar. > > Multiple different packages reusing the same name in subsequent releases > seems > pretty contrived to me, however. > > > All in all, I think your proposal is just a shorthand to make your > > debian/control marginally smaller and having to write extensive > > (slow[2]) patches to dpkg, but also britney, dak and pretty much > > everything dealing with .debs, for absolutely no real gain wrt the > > current state of stuff. > > I will concede that Supersedes should not imply Replaces or Conflicts, but > merely be a hint to APT. Then neither dpkg nor britney nor dak should need to > be patched. Though a question remains: Should dak reject a package that tries > to supersede a package of which a newer version already exists in the > archive? > I don't think so; the other 'foo' could be uploaded before the superseding > 'bar'. ... especially reading that. I answered thinking you meant Supersedes to be an alias for something complicated, not a hint for apt. As a hint, it's probably a worthwhile goal, and I -see- ways to even make it work for name reuse in subsequent releases. Actually with versioning enabled, it's even quite simple. Looking at your example, with <= in the versions instead of equality to make it more robust, lenny: git 4.3.20-10 git-core 1:1.5.6.5-3+lenny2 squeeze: gnuit 4.9.5-1 Supersedes: git (<= 4.9.5-1~) git 1:1.6.4.3-2 Supersedes: git-core (<= 1:1.6.4.3-2~) When a user upgrades, then /apt/ can grok that the proper upgrade path for 'git' coming from a version <= smaller than 4.9.5-1 is using gnuit instead. It can then just do what was suggested in another mail in the thread and migrate "autoinstalled" flags from git to gnuit. At the same way, the sole thing you need to prevent apt to consider upgrading git (aka gnuit) into git (the VCS) is to make sure that the "new" git has a strictly greater version than the package it replaces, which can always be done using the dreaded epochs (it's ugly, but fancy things like reusing a package name for two different things is hard, and it's logical there is a price to pay). So while I dismissed your idea at first thinking you wanted to make it a dpkg thing, now that I understand that you rather want it to be an /apt/ one, it makes really more sense to me. The point remains though that: - apt - dselect - aptitude - cupt must support that. I don't think in the end that britney or dak needs to grok this header after
Re: Faster boot by running init.d scripts in parallel
Petter Reinholdtsen wrote: > > One "hidden" feature of the current Debian boot sustem, is the ability > to run the init.d scripts in parallel. > some years back, richard lightman wrote depinit. it's a complete replacement for sysvinit, and it's a parallel initialisation system. unlike sysvinit, it caught _all_ signals on applications. i installed it several times, and it showed that startup time could be reduced from 2 minutes (800mhz PIII) to 25 seconds, and it showed that shutdown time can be reduced from 1-2 minutes to under 4 seconds. the reason for the fast shutdown time is that a) shutting down services typically takes a lot less time than starting them b) depinit would send increasingly drastic signals to kill a service. other nice features include: * monitoring and chasing with extreme aggression anything that looks like it's out-of-control. applications such as rootkits, which spawn child processes immediately on startup and on the death of the parent, are good candidates and were the driving force behind the decision * script / service chaining (applying the unix pipe philosophy, even to services). one "service" can output its stdout and/or stderr to _another_ service. richard utilised this e.g. on sshd and other services requiring authentication. by chaining the output from sshd into another script, he could monitor attacks against a server _live_ rather than "ohh let's run a cron job every minute and watch the sshd logs or something oh whoops, too late". so, the monitoring script could observe three login failures and *instantly* add a firewall rule. * automatic re-spawning of services AND termination of dependent services if re-spawning fails. this is a really important security feature. if the firewall doesn't come up, or any other particularly critical service (such as heartbeat monitoring service), do you REALLY want the dependent services to come up? automatic re-spawning basically does away with the [stupid] mysql monitoring script, which cannot do a proper job anyway, simply because the required signals cannot be properly caught [remember: depinit catches EVERYTHING]. that's not all - it's just everything i can remember. when i installed depinit, i had to spend considerable time customising udevscripts, in order to get some speed. the kinds of systems i was installing it on were waiting for 30 seconds on /sbin/udevsettle, due to the absolutely ridiculous numbers of pseudo ttys created by the debian linux kernel. 768 pseudo-ttys!!! come _on_. so, i broke it down into stages. the first udevsettle "service" created /dev/ttyNN and /dev/pty/NN and the second one would create and wait for /dev/ttyNNN and /dev/pty/NNN. critical services would then depend on the first udev service (such as filesystem mounts, networking, sshd etc) and non-critical services on the second. this trick was what got most of the boot time down. [btw it has to be said that udev and the udev scripts are an absolute dog's dinner. the amount of cpu time wasted by spawning /bin/sh 12 levels deep, almost a thousand times, is .. um... considerable.] also one other observation was that many of the scripts these days do _lots_ of "sleep" cycles. putting all of these in serial is a _total_ waste of time. also, richard observed that sysvinit [non-parallel] was created when context-switching was insanely expensive. CPUs now - even low-end ARMs - are pretty damn good at context switching. it's therefore absolutely pointless to stack initialisation scripts up in serial, even on a single CPU system, in the pretense of saving cycles, when you can throw out a hundred processes in parallel on most CPUs of the past decade and they'll not even break a sweat. anyway - i wanted to mention this because depinit remains absolutely streets ahead of anything else i've encountered, l. -- View this message in context: http://www.nabble.com/Faster-boot-by-running-init.d-scripts-in-parallel-tp25381465p25530129.html Sent from the Debian Devel mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DEP-5: an example parser, choice of syntax for Files:
apologies, i didn't find this thread until i talked on #debian-devel today, so um... i wrote my own :) http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/contrib/copyright_check.py?view=log pyjamas has 2,000 files, from a wide range of projects and sources: (fckeditor, python, random win32 mailing lists to name a few)) i sure as s**t wasn't going to check them manually. so i wrote copyright_check.py it's designed to match the debian/copyright file with the files that it finds in the "Files: " sections, looking for their copyright notices (as best can be found), then doing fuzzy-matching on the authors listed in the debian/copyright sections and those *actually* found in the files. [licensecheck would be a nice-to-have addition to the mix]. somehow, despite my boolean-logic dyslexia, i think i managed to print out only those copyright holders found _not_ listed in the debian/copyright file. there are limitations (listed at the top of the file) but copyright_check.py even managed to find the copyright holders listed in some .gif files. anyway - i'm happy to use this for pyjamas: it's made available to anyone else who might want to do something with it. l. -- View this message in context: http://www.nabble.com/DEP-5%3A-an-example-parser%2C-choice-of-syntax-for-Files%3A-tp25428186p25530132.html Sent from the Debian Devel mailing list archive at Nabble.com. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
On Sun, 20 Sep 2009, Marc Haber wrote: > As long as you do not expect me to manually sign every single upload, Why not? It is a package, it has root access anywhere it is being installed or removed. Even if you abuse the DM machinery to have a key restricted to only upload clamav-data, it would still be risky. As you said, you'd have to jump through a lot of loops to do special validation of that specific package before installing it. If it would still address whatever problem space clamav-data wants to fix, maybe it would be easier if you created a package-generator package (that creates a fresh clamav-data package for the user when, e.g. a create-clamav-data command is run). If someone has network access to fetch clamav-data, he also has network access to fetch the signatures, so he could run the "create-clamav-data" utility instead... > It would be massively easier if I knew what are the real issues What jumps immediately to mind is that someone could get a hold of that key, and upload a trojan or bomb that will run as root on anyone that installs (or removes, whatever) the package. > That being said, it looks like volatile's policies are going to change > BIG TIME when it gets integrated into the main archive, and frankly, > as a volatile user, I'd rather see volatile stay separate than seeing > some of its previous principles dumped. Do you have a very secure setup involving two boxes, one of which is fully offline and talks to the first one using a safe, restricted, application layer link to get the clamav data, and upload the finished package back to the first box? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547581: ITP: scilab-scimax -- Symbolic computations for Scilab based on Maxima
Package: wnpp Severity: wishlist Owner: Sylvestre Ledru * Package name: scilab-scimax Version : 2.0.1 Upstream Author : Calixte Denizet * URL : http://scilabtbxset.sourceforge.net/ * License : GPL Programming Lang: C, LISP, Scilab Description : Symbolic computations for Scilab based on Maxima This toolbox is providing symbolic capatibilities with the Scilab languages. . It is based on Maxima which is a fully symbolic computation program. It is full featured doing symbolic manipulation of polynomials, matrices, rational functions, integration, Todd-coxeter methods for finite group analysis, graphing, multiple precision floating point computation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547593: ITP: kaya-board -- Board game suite
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: kaya-board Version: 0.1.1 Upstream Author: Paolo Capriotti URL: http://pcapriotti.github.com/kaya/ License: GPL version 2 Description: Board game suite Kaya is a board game suite containing games such as Chess and Shogi. It is built upon a powerful plugin system which makes it easily extensible with new games, themes and behaviour. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547607: ITP: pion-net -- library for implementing lightweight HTTP interfaces
Package: wnpp Severity: wishlist Owner: "Roberto C. Sanchez" -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: pion-net Version : 2.1.8 Upstream Author : Atomic Labs, Inc. * URL : http://www.pion.org/projects/pion-network-library * License : Boost Software License 1.0 Programming Lang: C++ Description : library for implementing lightweight HTTP interfaces According to the upstream website (will be trimmed for packaging): Pion Network Library (pion-net) is a C++ development library for implementing lightweight HTTP interfaces. There are a wide variety of open source HTTP servers available, from fast and lightweight servers such as lighttpd, to full-featured platforms like Apache HTTPD. The motivation of pion-net is not to implement yet another web server, but to provide HTTP(S) functionality to new or existing C++ applications. If you're looking for a full-featured server application, we suggest that you use one of the projects above. If you're working on a Boost C++ application and would just like to use HTTP to provide a simple user interface or interact with run-time data, then pion-net is a much cleaner and simpler solution. Pion Network Library uses the Boost and asio libraries for multi-threading and asynchronous I/O. Multi-threading allows the use of multiple CPUs or processing cores to process HTTP requests simultaneously. Asynchronous I/O allows each thread to handle many connections simultaneously (otherwise, a single thread would be required for every connection to the server). The combination of these technologies takes full advantage of the most modern CPUs, and allows servers implemented using pion-net to handle many thousands of connections simultaneously with a single physical server. Pion Network Library lets you run multiple servers listening to any number of ports and network devices. Each server may have its own collection of web services defined which are bound to HTTP resources. Protocols other than HTTP can also easily be implemented for any server. A common thread pool is used to handle operations for all servers. pion-net also supports server-side SSL & TLS encryption when built with the OpenSSL library. - -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkq23wUACgkQ5SXWIKfIlGSKfACdHGPZ2nHEMJb11Ne0axaIsXe4 25IAni91ev5VDQx7yIIKZF34gERKavrW =hbE7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Seeking advice on packaging of pion-net
I am packaging pion-net [0], which is currently at version 2.1.8. Once built, the SONAMEs of the two shared library packages are: libpion-net-2.1.8.so libpion-common-2.1.8.so According to the Debian Library Packaging Guide [1], with SONAMEs like that, the packages should be named libpion-net-2.1.8 and libpion-common-2.1.8. However, I am not certain what the "best" way to handle this is. I am currently thinkging of naming the packages like this: Source: pion-net Binary: libpion-net-dev, libpion-net-2.1.8, libpion-common-2.1.8, libpion-net-2.1.8-dbg, libpion-common-2.1.8-dbg, libpion-net-doc The problem, as I see it, with this arrangement is, that when a new upstream released, like 2.1.9, then four of the package names will change, resulting in the need for the new upstream to pass NEW processing. I don't currently plan to package and reverse dependencies. However, that is not to say that someone else will not in the future. I have looked at how some other packages handle it (e.g., boost), but they version even the -dev package and source package, so that each new upstream release results in a new source package. I'm not sure if that approach would work or is appropriate for this package. Any advice/insights on this would be appreciated. Regards, -Roberto [0] http://bugs.debian.org/547607 [1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#547611: RFH: geomview -- interactive geometry viewing program
Package: wnpp Severity: normal Hi, I'd appreciate someone to help with maintenance of geomview. The package description is: Geomview is interactive geometry software which is particularly appropriate for mathematics research and education. In particular, geomview can display things in hyperbolic and spherical space as well as Euclidean space. . Geomview allows multiple independently controllable objects and cameras. It provides interactive control for motion, appearances (including lighting, shading, and materials), picking on an object, edge or vertex level, snapshots in SGI image file or Renderman RIB format, and adding or deleting objects is provided through direct mouse manipulation, control panels, and keyboard shortcuts. External programs can drive desired aspects of the viewer (such as continually loading changing geometry or controlling the motion of certain objects) while allowing interactive control of everything else. Homepage: http://www.geomview.org. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
On Sun, 20 Sep 2009 18:28:30 -0300, Henrique de Moraes Holschuh wrote: >On Sun, 20 Sep 2009, Marc Haber wrote: >> As long as you do not expect me to manually sign every single upload, > >Why not? Because nobody pays me to spend an hour a day to sign packages. We had three full cycles since I went to bed seven hours ago. > It is a package, it has root access anywhere it is being installed >or removed. And people know that the package is built automatically. All users I know especially opted in to using the package instead of freshclam for some-or-other reason. >As you said, you'd have >to jump through a lot of loops to do special validation of that specific >package before installing it. ... which can be fully automated. >If it would still address whatever problem space clamav-data wants to fix, >maybe it would be easier if you created a package-generator package (that >creates a fresh clamav-data package for the user when, e.g. a >create-clamav-data command is run). See clamav-getfiles. The script which build the package is - of course - packaged. I guess that you didn't even look at whet you're trying to kill. > If someone has network access to fetch >clamav-data, he also has network access to fetch the signatures, so he could >run the "create-clamav-data" utility instead... This assumption is wrong. >> It would be massively easier if I knew what are the real issues > >What jumps immediately to mind is that someone could get a hold of that key, >and upload a trojan or bomb that will run as root on anyone that installs >(or removes, whatever) the package. Not if the key would be limited to clamav-data only and if the archive would verify whether the new package only differs to some "golden" package in the actual signatures. >> That being said, it looks like volatile's policies are going to change >> BIG TIME when it gets integrated into the main archive, and frankly, >> as a volatile user, I'd rather see volatile stay separate than seeing >> some of its previous principles dumped. > >Do you have a very secure setup involving two boxes, one of which is fully >offline and talks to the first one using a safe, restricted, application >layer link to get the clamav data, and upload the finished package back to >the first box? No. The process runs on a virtual machine on a host privately owned and operated by the previous ftpmaster of Debian volatile, and was carefully designed in close cooperation with the former Debian volatile team. It is a real shame that the new Debian volatile team decided to put up more hoops to jump through after clamav-data was one of the first packages to be included with Debian volatile. Oh well, some more motivation to work on Debian going down the drain. Well done. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: opposition against clamav-data in debian volatile
Marc Haber wrote: > On Sun, 20 Sep 2009 18:28:30 -0300, Henrique de Moraes Holschuh > wrote: >> On Sun, 20 Sep 2009, Marc Haber wrote: > No. The process runs on a virtual machine on a host privately owned > and operated by the previous ftpmaster of Debian volatile, and was > carefully designed in close cooperation with the former Debian > volatile team. It is a real shame that the new Debian volatile team > decided to put up more hoops to jump through after clamav-data was one > of the first packages to be included with Debian volatile. Please stop spreading FUD. The extended team decided to try to integrated with the main archive. The ftpmasters of the main archive have more strict rules about how packages can be accepted, though it will still be the volatile team that decides which packages could go in. The time complaining in this thread could probably better spent by talking to ftpmas...@d.o and implementing a solution btw. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547617: ITP: pymetrics -- Python code metric reporting tool
Package: wnpp Severity: wishlist Owner: Andrew Pollock * Package name: pymetrics Version : 0.8.1 Upstream Author : Reg. Charney * URL : http://sourceforge.net/projects/pymetrics * License : GPL Programming Lang: Python Description : Python code metric reporting tool PyMetrics produces metrics for Python programs. Metrics include McCabe's Cyclomatic Complexity metric, LoC, %Comments, etc. Users can also define their own metrics using data from PyMetrics. PyMetrics optionally outputs stdout, SQL command files and CSV -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Seeking advice on packaging of pion-net
On 11880 March 1977, Roberto C. Sánchez wrote: > Source: pion-net > Binary: libpion-net-dev, libpion-net-2.1.8, libpion-common-2.1.8, > libpion-net-2.1.8-dbg, libpion-common-2.1.8-dbg, libpion-net-doc > The problem, as I see it, with this arrangement is, that when a new > upstream released, like 2.1.9, then four of the package names will > change, resulting in the need for the new upstream to pass NEW > processing. I don't currently plan to package and reverse dependencies. > However, that is not to say that someone else will not in the future. No matter if you package -net and -common in one or two or four packages - as you will have something changing in the package name when SONAME changes, you *will* have a run through NEW. There is no way you can avoid this, so looking at it from that POV is wasted time. :) > I have looked at how some other packages handle it (e.g., boost), but > they version even the -dev package and source package, so that each new > upstream release results in a new source package. I'm not sure if that > approach would work or is appropriate for this package. Boost is nothing to compare yourself with. And having even source and -dev versioned is usually unwanted. There are exceptions to that rule, but usually you do want them unversioned. > Any advice/insights on this would be appreciated. Do it right :) -- bye, Joerg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
