Re: Finding missing epochs
Le jeudi 05 juillet 2012 à 23:34 +0200, Jakub Wilk a écrit : > I wrote a tool to detect versioned (build-)dependencies with possible > missing (or insufficient) epochs. The results for unstable and a DD-list > are attached. Thanks a lot for this tool, it is very useful. Note that dh_devlibs (#534966) would avoid quite a number of these errors. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1341562166.21607.214.camel@pi0307572
Re: EFI in Debian
Le vendredi 06 juillet 2012 à 05:32 +0100, Ben Hutchings a écrit : > 1. General consensus in the project that supporting the option of Secure > Boot, including purchase of a Microsoft-signed certificate, is > worthwhile and not entirely objectionable. Not entirely objectionable indeed, but it really depends on what we would have to pay for. As long as it is only covering for administrative costs of Microsoft emitting a new certificate, it is fine. If OTOH we have to pay a fee just for our software to work on platforms that just happen to be using Microsoft’s certificate, this is clearly abusive. I would object to do so, and I believe we would (at least in Europe) have a very strong case in court against such practice. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1341562441.21607.269.camel@pi0307572
Bug#680475: ITP: jsamp -- Java toolkit for use with the Simple Application Messaging Protocol
Package: wnpp Severity: wishlist Owner: Florian Rothmaier * Package name: jsamp Version : 1.3.2 Upstream Author : Mark Taylor * URL : http://software.astrogrid.org/doc/p/jsamp/1.3-2/index.html * License : BSD Programming Lang: Java Description : Java toolkit for use with the Simple Application Messaging Protocol JSAMP provides a hub implementation for the Simple Application Messaging Protocol (SAMP), suitable for standalone or embedded use. . Moreover, it offers a set of classes which can be used to implement SAMP capabilities in client applications. JSAMP provides a hub test and a benchmarking suite to examine the correctness and performance of third-party hub implementations. The software includes hub and client implementations of the standard and web profiles and a bridge component, which allows clients on different hubs to talk to each other. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706081237.7205.40080.reportbug@auva224
Re: Bug#680226: lib{nss,pam}-ldapd: apt wants to remove them on dist-upgrade in favour of lib{nss,pam}-ldap:i386
On Fri, Jul 6, 2012 at 12:06 AM, Arthur de Jong wrote:
> I guess the conflicts is interpreted to apply to any installed version
> of the package while what should be interpreted as a conflict/replaces
> only of the package of the same architecture.
Correct guess. "Negative dependencies" (Breaks, Conflicts, …) apply
to all architectures. (Any) architecture-specific dependencies are not
allowed in wheezy as APT and dpkg gained support for them only very
very recently, thanks to Thibaut Girka. I am not sure if they are allowed
even then in negatives though (and I doubt APT supports them there
currently).
Long story short:
> I'm not sure what the proper way is to specify that Conflicts and
> Provides should only apply for a same-architecture version of the
> package. If I do this (just trying some things):
There is simple no way.
> Provides: libnss-ldap:${Arch}
Provides on the other hand are architecture specific by default.
They are only non-architecture specific if you mark the package
M-A:foreign - I hope it is obvious why.
> # dpkg -i libnss-ldapd_0.8.10-2_i386.deb
> dpkg: error processing libnss-ldapd_0.8.10-2_i386.deb (--install):
> parsing file '/var/lib/dpkg/tmp.ci/control' near line 9 package
> 'libnss-ldapd':
> 'Conflicts' field, reference to 'libnss-ldap': invalid architecture name
> 'i386': a value different from 'any' is currently not allowed
Which dpkg version is that?
But as said, you can't use architecture specific dependencies in wheezy.
(The message is a bit confusing, :any doesn't make a lot of sense here
provided that it is the same without :any … or worse: any could mean
we are conflicting only with one arch at random, if you have a second
installed you might be lucky - or not - depending on moon phase)
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fa2r+tbsxscau6mnimzfdm4tyggs+zmb__f0r9ez8e...@mail.gmail.com
Bug#680477: ITP: rmilite -- Java implementation of the Remote Method Invocation protocol
Package: wnpp Severity: wishlist Owner: Florian Rothmaier * Package name: rmilite Version : 1.0 Upstream Author : Charles Lowell * URL : http://sourceforge.net/projects/rmi-lite/ * License : LGPL Programming Lang: Java Description : Java implementation of the Remote Method Invocation protocol RMILite is an ultra-thin layer which sits on top of the Java Remote Method Invocation (RMI) protocol. It allows its users to export arbitrary objects without having to extend Remote, to run rmic, or to declare all methods to throw a RemoteException. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706083742.7661.98533.reportbug@auva224
Re: Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]
On Thu, Jul 05, 2012 at 05:39:07PM -0700, Rick Thomas wrote: > The fundamental problem we must solve is allowing the *user* to > securely choose which OS she wants to install. No. The user can disable secure boot. > Whether that OS > follows thru and verifies all its parts is between the user and the > person or group who provided the OS (could be the user, herself, of > course!) No, this is not voluntary. If we get a loader signed by an external entity, it have to fulfill the requirements, aka no execution of unsigned code in the kernel. > Would this work? What have I missed? You show a fundamental missinterpretation of the goals of secure boot. I see nothing worth commenting on. Bastian -- The man on tops walks a lonely street; the "chain" of command is often a noose. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706090215.gb19...@wavehammer.waldi.eu.org
Re: Bug#680226: lib{nss,pam}-ldapd: apt wants to remove them on dist-upgrade in favour of lib{nss,pam}-ldap:i386
[… “interesting” M-A consequences …] Oh, sorry for disturbing an anthill then. This sounds entirely nōn-trivial to solve… Could this work: libnss-ldap and libnss-ldapd both provide the same virtual package and conflict with it? Same for the pam ones but a different virtual package. Just a wild-guess, //mirabilos -- 21:27⎜[Natureshadow] BÄH! Wer hatn das Bier neben den Notebooklüfter ⎜gestellt ... 21:27⎜>Natureshadow< lol 21:27⎜>Natureshadow< du? 21:27⎜[Natureshadow] vermutlich ... -- Kev^WNatureshadow allein zu Haus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1207061100300.19...@herc.mirbsd.org
Re: EFI in Debian
On 06/07/12 06:32, Ben Hutchings wrote: > 1. General consensus in the project that supporting the option of Secure > Boot, including purchase of a Microsoft-signed certificate, is > worthwhile and not entirely objectionable. (I am assuming that it would > be a waste of time to use our own platform key, as anyone who can work > out how to install that can also disable Secure Boot.) > This are the FSF recommendations: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web Regards! -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Re: Bug#679236: O: ckport -- portability analysis and security checking tool
reflum,
On Thu, 2012-06-28 at 13:05 +0100, Ian Jackson wrote:
> Philipp Schafft writes ("Re: Bug#679236: O: ckport -- portability
> analysis and security checking tool"):
> > On Wed, 2012-06-27 at 22:50 +0200, Thomas Preud'homme wrote:
> > > What is the link between celt and ckport? I mean, why does this
> orphaning
> > > message refers (implicitely) to celt?
> >
> > The CELT problem as been fixed. The problem with Ron Lee is that he
> > removed all rdepends on libroar wich makes it useless *AFTER* the
> CELT
> > problem has been fixed. In fact I know of no problem with libroar
> wich
> > justify such a step (-> removing all rdeps means making it unusable
> for
> > it's users -> no need to skip it anymore). There are *no* open bug
> > reports nor was I informed of any problem using another channel.
>
> According to
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674649
> the dependency on celt was removed from libroar on the 6th of June.
>
> > >from libao's changelog (1.1.0-2):
> > >* End the grief with roar.
> > > Too many people now have been through all the stages of
> Denial, Anger,
> > > Bargaining, and Depression with it, so it's time to accept
> the only
> > > sensible course of direct action that remains to preserve
> sanity.
> > > Closes: #667039
> >
> > The bug only asks for updating a recommends after transition (SONAME
> > change).
>
> This was on the 2nd of June. At this stage, a few weeks before
> freeze, libao was inheriting the problems of celt via roaraudio. When
> celt is removed by its maintainer, libao would become uninstallable.
>
> Given that you as the roaraudio maintainer had strongly resisted Ron's
> efforts to fix this in roaraudio, even to the point of objecting to a
> proposed NMU, Ron had no other real option at that point.
The problem was caused by Ron Lee being very late and not informing
anybody of what he was doing. Something he always does: wouldn't it be
natural to inform maintainers then removing dependencys and requesting
other packages to do the same? this includes openal, cmus and ices2 for
example. don't know a complet list as Ron is not telling anything...
But I thank you very much for suspecting me to break my own package by
fully ignoring it. Why not first cosider the positive case: The
maintainers working on the problem. That was exactly the case. We
checked a lot options and looked up code. Stuff that not happens in BTS
and that takes time. Time Ron was not giving us.
> I do agree that his words were harsh and it would have been better if
> the changelog entry had been more polite. But I don't think it
> amounts to hate speech.
The hate speech was mostly on IRC and mail.
> > In addition I needed to listen a lot to his hate speach against me
> on
> > IRC and bugs,
>
> Unless you have better examples, you are overreacting.
see above.
> > As nobody seemd to be interested in this case I decided to leave the
> > Debian project. I don't see a point in getting flamed for trying my
> very
> > best to ensure quality of packages just to finally waste my time by
> > other people rendering the packages useless.
>
> It is of course always sad to see someone leave. Often in the past we
> have had people driven out by poor behaviour of other members of the
> project. But based on what I've seen I don't think that's the case
> here.
>
> The reason I am explaining all this is not to persuade you. I'm
> explaining it in the hope that others in the project will see what has
> happened and avoid similar situations in the future.
I think it will stop happening then a random person in the project can
no longer render weeks of work of other persons perfectly useless.
The project should care more for users than internal conflicts like
this. My users already asking me (upstream) what happend. I would be
glad to spend my time to the Debian project in a useful way. But I don't
see how this is given anymore. Also my users complain about the
situation and I'm not willing to be the person they make responsible for
(because I'm in the maintainer team) packages made perfectly useless by
others.
PS: Release wasn't helpful in this case as well. They tell me they have
no opinion and are not interested in getting this fixed for stable (was
asking *before* freeze). I'm not mad on anyone of them personally, just
I don't think it is the right way to go.
--
Philipp.
(Rah of PH2)
signature.asc
Description: This is a digitally signed message part
Bug#680507: ITP: norsp -- predictor of non-regular secondary structure of proteins
Package: wnpp Severity: wishlist Owner: e.reisin...@gmx.net * Package name: norsp Version : 1.0.3 Upstream Author : Laszlo Kajan * URL : http://www.rostlab.org/ * License : GPL Programming Lang: Perl Description : predictor of non-regular secondary structure of proteins Many structurally flexible regions play important roles in biological processes. It has been shown that extended loopy regions are very abundant in the protein universe and that they have been conserved through evolution. Here, we present NORSp, a publicly available predictor for disordered regions in protein. Specifically, NORSp predicts long regions with NO Regular Secondary structure. Upon user submission of a protein sequence, NORSp will analyse the protein for its secondary structure, presence of transmembrane helices and coiled-coil. It will then return email to the user about the presence and position of disordered regions. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706124916.16142.85285.report...@i12r-tbl.informatik.tu-muenchen.de
Re: Bug#679236: O: ckport -- portability analysis and security checking tool
On Fri, Jul 06, 2012 at 02:49:54PM +0200, Philipp Schafft wrote: > PS: Release wasn't helpful in this case as well. They tell me they have > no opinion and are not interested in getting this fixed for stable (was > asking *before* freeze). I'm not mad on anyone of them personally, just > I don't think it is the right way to go. > For avoidance of doubt, the release team as a whole did not say anything of the sort. I personally, and not any other member of the release team gave the opinion that this ongoing argument is not something I wanted to get involved with, and that I would not try to dictate a developer's actions in this way. References can be found in the debian-release archives, http://lists.debian.org/debian-release/2012/06/msg00388.html and beyond. Neil signature.asc Description: Digital signature
Re: EFI in Debian
On Fri, Jul 6, 2012 at 5:41 AM, Carlos Alberto Lopez Perez wrote: > This are the FSF recommendations: > > http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web These seem much more in line with the Debian social contract than any the actions of other distributions or of the suggestions we have had. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6gdau-v4bb4xwwpcgspn0neofpr0o4vfzegqcxqxjd...@mail.gmail.com
Bug#680539: ITP: hmmer2 -- profile hidden Markov models for protein sequence analysis (version 2)
Package: wnpp Severity: wishlist Owner: Laszlo Kajan -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: hmmer2 Version : 2.3.2 Upstream Author : Sean Eddy * URL : ftp://selab.janelia.org/pub/software/hmmer/ * License : GPL-2+ Programming Lang: C Description : profile hidden Markov models for protein sequence analysis (version 2) HMMER is an implementation of profile hidden Markov model methods for sensitive searches of biological sequence databases using multiple sequence alignments as queries. . Given a multiple sequence alignment as input, HMMER builds a statistical model called a "hidden Markov model" which can then be used as a query into a sequence database to find (and/or align) additional homologues of the sequence family. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJP9xa1AAoJEJvS1kCaDFL6PPUP/2wv/UE5wlNQ2tYLlRxR7uOO eQ0im3kI1OGHg9BSnhJ6QUMrHJE/O5sRNOL/lvY7AuaRsVyxXXq1+jdCH3YrME92 vh3jSX7/cX2f0Hq/cSWI6Vq60H7MlShP6kNaSrEnMcpRDKUaaeKhR4/CHuzSYMoM dctuImUHKkP8gjBTa8OXX4Y+AaPihOrfBIdcLUhQ9gCRUxi2GdGZU4kbO+KgL1Hm jC9bAlTXwY4kKGCHOYlMN6VV5WK6M6fXjhP/gHCYJ4+zNx4s5nETUTbTkBSPsMw2 Ct3UHhCNm6VgskLrBHI9/TdQnfRE+rX9KZ2r5LORu2xNlFsIxxGKAOKMc90fRRu4 Ms/KsBznt96GOlcGQgb0WwnMZuVYk9LvOHadSPMglZlbQkMopwiS969hdykuoWaT NtSosLQG5wra0feGi1FGEVA2dOx13KlgjeUxQ3NDiWFbRGqtcuXerLVfEwou69gq NJ2adWRoV2O3KTQo1u00GXfBhtlmKxkJJsBn4LtdfYfjaJNY+83SUsjXs8A1HVSt Keer95A3aOCh4djwCu+l1t8u6nSXFniuwsmIWgx+0zN/74r4VJRSeHRG9eJxczkw N2hM18j/7PJzfgQUx2tqacYsxS4aUcqK9xaaw2CBHtDTG3tvmAHTJJod9MclslhM SnteNltP14xthG1DyneD =QOd2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706164754.26280.39267.reportbug@debian-unstable.rostclust
Re: Finding missing epochs
]] Jakub Wilk > I wrote a tool to detect versioned (build-)dependencies with possible > missing (or insufficient) epochs. The results for unstable and a > DD-list are attached. Thanks, this looks like a useful tool. results for chef and varnish, while not wrong, are harmless, since there's no version too old in the archive to satisfy the requirement, even without a version. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762a0x1ba@xoog.err.no
Re: Bug#680539: ITP: hmmer2 -- profile hidden Markov models for protein sequence analysis (version 2)
Hello, Laszlo Kajan wrote on 2012-07-06 18:47: > HMMER is an implementation of profile hidden Markov model methods for > sensitive searches of biological sequence databases using multiple sequence > alignments as queries. Which software/packages do you use together with this package? Is there a way to use this package directly together with some speech recognition software: cmusphinx or simon/julius? --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706194341.7d61e...@jupiter.home
Re: Bug#680539: ITP: hmmer2 -- profile hidden Markov models for protein sequence analysis (version 2)
On Fri, Jul 06, 2012 at 07:43:41PM +0200, Joachim Wiedorn wrote: > Laszlo Kajan wrote on 2012-07-06 18:47: > > HMMER is an implementation of profile hidden Markov model methods for > > sensitive searches of biological sequence databases using multiple sequence > > alignments as queries. > Is there a way to use this package directly together with some speech > recognition software: cmusphinx or simon/julius? HMMER ist for protein and nucleotid data. Not natural text. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706190415.ga28...@wavehammer.waldi.eu.org
Re: ITP: clean - The Clean language compiler (bug 680061)
On Wed, Jul 4, 2012 at 6:31 PM, Paul Wise wrote: >> I intend to package the Clean language compiler for Debian. > > That is a very generic name, please use at least clean-compiler or As you can see in the bug, I just let DBS change the name to clean-compiler, as you suggested. > similar for the source/binary package names. On IRC someone said that > it does not use /usr/bin/clean so that part should be fine. Indeed it does not use /usr/bin/clean, only /usr/bin/clm (Clean Make) and /usr/bin/htoclean (C Header to Clean). > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/camd+psdgprc5ta-74qnkdwtn+fa3fboqrzvdhccjcbqjjr7...@mail.gmail.com
Bug#680572: ITP: nemu -- A lightweight network emulator embedded in a small python library
Package: wnpp Severity: wishlist Owner: "Martín Ferrari" * Package name: nemu Version : 0.1 Upstream Author : Martín Ferrari , Alina Quereilhac * URL : http://code.google.com/p/nemu/ * License : GPLv2 Programming Lang: Python Description : A lightweight network emulator embedded in a small python library Nemu (Netwok EMUlator) is a small Python library to create emulated networks and run and test programs in them. Different programs, or copies of the same program, can run in different emulated nodes, using only the emulated network to communicate, without ever noticing they all run in the same computer. Nemu provides a very simple interface to create nodes, connect them arbitrarily with virtual interfaces, configure IPv4 and IPv6 addresses and routes, and start programs in the nodes. The virtual interfaces also support emulation of delays, loss, and reordering of packets, and bandwidth limitations. More advanced configurations, like setting up netfilter (iptables) rules, starting VPN tunnels, routing daemons, etc, are simply supported by executing the appropriate commands in the emulated nodes, exactly as if they were executed in real machines in a real network. You can even start interactive sessions by opening xterms on different nodes, Nemu has special support for forwarding X sessions to the emulated nodes. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706205055.4299.69209.report...@abhean.lan
CD sizes again (and BoF reminder!)
Hey people, Following up on this again... Back in May I warned about CD sizes[1] for the Wheezy release, pointing out that CD#1 isn't big enough any more to provide usable Gnome or KDE installations. There was some discussion about what to do about that (change compression to xz, switch to the lighter desktops by default, require more than one CD, recommend DVDs instead), then Joey pointed out that the existing setup in debian-cd wasn't working correctly with existing tasks since we switched to task packages. I fixed that a while ago and pointed to the results [2], but they're still not encouraging. I've just checked on the builds from this week's run on amd64 and updated the sorted package lists. What I'm seeing now is: Gnome = The last package on amd64 CD#1 is gnome-packagekit-data. task-desktop fits on CD#1, but task-gnome-desktop is ~110 packages into CD#2. gnome-shell-common doesn't even make CD#1, which means the desktop will be a little... sparse. The full sorted package list is at http://cdimage.debian.org/cdimage/tmp/new-tasks/gnome-cd.list.gz KDE === The last package on amd64 CD#1 is libkontactinterface4. task-desktop fits on CD#1, but task-kde-desktop is about 60 packages into (what would be) CD#2. The full sorted package list is at http://cdimage.debian.org/cdimage/tmp/new-tasks/kde-cd.list.gz LIGHT (lxde/xfce) = The last package on amd64 CD#1 is libmng1. The core tasks fit fine (task-desktop, task-lxde-desktop, task-xfce-desktop), well within the the space of CD#1. Full sorted list at http://cdimage.debian.org/cdimage/tmp/new-tasks/light-cd.list.gz I'm going to talk about this more at the debian-cd BoF on Monday (17:00 local time, 23:00 UTC). In the mean time, please feel free to ask questions... [1] https://lists.debian.org/debian-cd/2012/05/msg00025.html [2] https://lists.debian.org/debian-cd/2012/06/msg00010.html -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706211004.ga14...@einval.com
Re: CD sizes again (and BoF reminder!)
Steve McIntyre writes: > Back in May I warned about CD sizes[1] for the Wheezy release, > pointing out that CD#1 isn't big enough any more to provide usable > Gnome or KDE installations. Indeed. CD1 was really problematic in squeeze too: http://lists.debian.org/debian-boot/2011/08/msg00172.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84zk7cwpf1@sauna.l.org
Bug#680576: ITP: libalgorithm-combinatorics-perl -- Efficient generation of combinatorial sequences in Perl/XS
Package: wnpp Severity: wishlist Owner: "Harlan Lieberman-Berg" * Package name: libalgorithm-combinatorics-perl Version : 0.27 Upstream Author : Xavier Noria * URL : http://search.cpan.org/~fxn/Algorithm-Combinatorics/ * License : Perl Programming Lang: Perl, C Description : Efficient generation of combinatorial sequences in Perl/XS Algorithm-Combinatorics is an efficient generator of combinatorial sequences. All algorithms are selected from the literature. Iterators do not use recursion, nor stacks, and are written in C. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706230557.10428.66167.report...@debian.bos.chitika.net
Re: Bug#679078: ITP: acpi-support-minimal -- minimal acpi scripts
❦ 26 juin 2012 14:48 CEST, Michael Meskes : >> I'll be reopening 665987, but if that gets closed again I'd be very >> happy to switch to acpi-support-minimal from my now locally built >> acpi-support packages w/ the consolekit dependency removed. > > I'm not sure I like the attitude here. "If that gets closed again" sounds like > I was closing the bug without a reason, which I didn't. I'm absolutely willing > to listen to ideas of solving this, which imo would be a much better solution > than creating an additional package that will only partly work. But please > don't > forget that upstream started using consolekit for a reason. The bug is already closed but I'd like to share another solution: I am using "acpi_fakekey $KEY_COFFEE" which sends XF86ScreenSaver key to the currently displayed X server. This is not foolproof (only one X server, only if it is currently displayed) but it is far simpler than other solutions. -- Don't stop with your first draft. - The Elements of Programming Style (Kernighan & Plauger) pgpHazP7UuTUH.pgp Description: PGP signature
Re: CD sizes again (and BoF reminder!)
As suggested by Ansgar IRL, here's a summary of what compression types are showing up on each CD (by looking at data.tar.$EXT for all the .debs and .udebs): >Gnome >= > >The last package on amd64 CD#1 is gnome-packagekit-data. task-desktop >fits on CD#1, but task-gnome-desktop is ~110 packages into >CD#2. gnome-shell-common doesn't even make CD#1, which means the >desktop will be a little... sparse. The full sorted package list is at > > http://cdimage.debian.org/cdimage/tmp/new-tasks/gnome-cd.list.gz bz2 16 deb xz8 deb, 157 udeb gz 897 deb, 60 udeb >KDE >=== > >The last package on amd64 CD#1 is libkontactinterface4. task-desktop >fits on CD#1, but task-kde-desktop is about 60 packages into (what >would be) CD#2. The full sorted package list is at > > http://cdimage.debian.org/cdimage/tmp/new-tasks/kde-cd.list.gz bz2 17 deb xz6 deb, 157 udeb gz 879 deb, 60 udeb >LIGHT (lxde/xfce) >= > >The last package on amd64 CD#1 is libmng1. The core tasks fit fine >(task-desktop, task-lxde-desktop, task-xfce-desktop), well within the >the space of CD#1. Full sorted list at > > http://cdimage.debian.org/cdimage/tmp/new-tasks/light-cd.list.gz bz2 23 deb xz 28 deb, 157 udeb gz 877 deb, 60 udeb -- Steve McIntyre, Cambridge, UK.st...@einval.com "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120707005927.gt4...@einval.com
Re: Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]
On Fri, 2012-07-06 at 11:02 +0200, Bastian Blank wrote: > On Thu, Jul 05, 2012 at 05:39:07PM -0700, Rick Thomas wrote: > > The fundamental problem we must solve is allowing the *user* to > > securely choose which OS she wants to install. > > No. The user can disable secure boot. > > > Whether that OS > > follows thru and verifies all its parts is between the user and the > > person or group who provided the OS (could be the user, herself, of > > course!) > > No, this is not voluntary. If we get a loader signed by an external > entity, it have to fulfill the requirements, aka no execution of > unsigned code in the kernel. That was my first reaction. But I'm not sure it's correct. > > Would this work? What have I missed? > > You show a fundamental missinterpretation of the goals of secure boot. I > see nothing worth commenting on. The goal is to prevent malware from persistently subverting a legitimate OS kernel, even if it tricks the user or the kernel into letting it install a boot loader or kernel module. So, if some hypothetical boot loader handles the appearance of some unsigned boot payload by asking 'do you really want to boot this?', of course the naive user will answer 'yes, I want to boot my computer'. Malware will then use that boot loader as its first stage and it will end up blacklisted. However, if the process of making the hypothetical boot loader trust new boot code involves a more active decision on the user's part (and if that decision cannot be automated by malware), it might possibly be sufficient to keep it from being exploited and blacklisted. But perhaps there are formal requirements that I'm not aware of, that would still forbid this. Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
Re: CD sizes again (and BoF reminder!)
Hi, Steve McIntyre writes: > Back in May I warned about CD sizes[1] for the Wheezy release, > pointing out that CD#1 isn't big enough any more to provide usable > Gnome or KDE installations. There was some discussion about what to do > about that (change compression to xz, switch to the lighter desktops > by default, require more than one CD, recommend DVDs instead), [...] I tried recompressing all packages in wheezy with xz. The total size for all amd64+all packages was reduced from 42GB to 33 GB (about 20%). A per-package listing is available from [1] [1] <http://people.debian.org/~ansgar/wheezy-20120706-with-xz.txt.gz> Would this be enough to make GNOME and/or KDE installable from a single CD image? Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vci0nulr@marvin.43-1.org
Re: CD sizes again (and BoF reminder!)
On Fri, Jul 06, 2012 at 09:00:32PM -0600, Ansgar Burchardt wrote: >Hi, > >Steve McIntyre writes: >> Back in May I warned about CD sizes[1] for the Wheezy release, >> pointing out that CD#1 isn't big enough any more to provide usable >> Gnome or KDE installations. There was some discussion about what to do >> about that (change compression to xz, switch to the lighter desktops >> by default, require more than one CD, recommend DVDs instead), [...] > >I tried recompressing all packages in wheezy with xz. The total size >for all amd64+all packages was reduced from 42GB to 33 GB (about 20%). >A per-package listing is available from [1] > > [1] <http://people.debian.org/~ansgar/wheezy-20120706-with-xz.txt.gz> > >Would this be enough to make GNOME and/or KDE installable from a single >CD image? Using rough calculation: * For GNOME, it takes about 185MB out of the space used to get up to task-gnome-desktop. Instead of being ~90MB into CD#2, that's ~100MB inside CD#1. * For KDE, it takes about 170MB out of the space used to get up to task-kde-desktop. Instead of being ~70MB into CD#2, that's ~100MB inside CD#1. So, yes - looks like xz will make a difference here for the wheezy release, for amd64 at least. It's enough that we'd probably even have space for the installation manual and release notes to fit \o/. i386 is still worse off (2 kernels instead of 1), but I don't have the exact figures to hand. -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120707034735.gu4...@einval.com
