credentials config at pkg install
Hi, I plan to package a perl script to run as daemon. It will update dynamic DNS provider with IP changes etc., but for that it needs user credentials registered at provider's web site beforehand. Is it a good solution to ask for credentials at package installation step? These credentials and other configurations I plan to put under /etc. If that's OK solution, could you please point me to some example package doing similar thing? Thanks, Eugene -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPqGMfJLcNjkm+TuLSKZmo8=crs1w-ac8d2swzruqnjxeo3...@mail.gmail.com
Re: credentials config at pkg install
+++ Eugene Zhukov [2014-12-11 13:12 +0200]: > Hi, > > I plan to package a perl script to run as daemon. It will update > dynamic DNS provider with IP changes etc., but for that it needs user > credentials registered at provider's web site beforehand. > Is it a good solution to ask for credentials at package installation > step? These credentials and other configurations I plan to put under > /etc. > If that's OK solution, could you please point me to some example > package doing similar thing? AICCU asks for similar details IIRC. Have a look at that? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014123005.gz27...@stoneboat.aleph1.co.uk
Re: credentials config at pkg install
On Thu, Dec 11, 2014 at 11:30:06AM +, Wookey wrote: > +++ Eugene Zhukov [2014-12-11 13:12 +0200]: > > Hi, > > > > I plan to package a perl script to run as daemon. It will update > > dynamic DNS provider with IP changes etc., but for that it needs user > > credentials registered at provider's web site beforehand. > > Is it a good solution to ask for credentials at package installation > > step? These credentials and other configurations I plan to put under > > /etc. > > If that's OK solution, could you please point me to some example > > package doing similar thing? > > AICCU asks for similar details IIRC. Have a look at that? You can look at ddclient as well. -- Antonio Terceiro signature.asc Description: Digital signature
Bug#772818: ITP: chaps -- PKCS#11 implementation for TPM backed services
Package: wnpp Severity: wishlist Owner: David Drysdale * Package name: chaps Version : 0.1 Upstream Author : ChromiumOS Authors * URL : https://github.com/google/chaps-linux * License : BSD Programming Lang: C++ Description : PKCS#11 implementation for TPM backed services Chaps is a PKCS #11 implementation, originally created for ChromiumOS, that provides trusted platform module (TPM) backed cryptographic services. It aims to improve speed and reliability of cryptographic token operations as well as to provide a simpler and more flexible codebase for future enhancements. Chaps works with a TCG Software Stack (TSS). Typically the TrouSerS TSS implementation is used, but Chaps is not limited to working with TrouSerS. The name "Chaps" has no real significance other than its fitness as a name for a layer above TrouSerS. The chaps source package is used to generate two binary packages: - The chaps binary package include the Chaps daemon and a PAM module which, if enabled, generates a PKCS #11 token for each user that logs into the system. - The libchaps0 binary package provides the client shared library that applications link to in order to use the PKCS#11 API. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014124818.22772.64548.report...@drysdale.lon.corp.google.com
Re: credentials config at pkg install
❦ 11 décembre 2014 13:12 +0200, Eugene Zhukov : > I plan to package a perl script to run as daemon. It will update > dynamic DNS provider with IP changes etc., but for that it needs user > credentials registered at provider's web site beforehand. > Is it a good solution to ask for credentials at package installation > step? These credentials and other configurations I plan to put under > /etc. > If that's OK solution, could you please point me to some example > package doing similar thing? You can do that with debconf and ucf. debconf will ask for the values, you will build a candidate configuration file from there and use ucf to prompt the user to accept changes if any. grub2 is doing that to manage /etc/default/grub. Maybe there are simpler examples. -- Localise input and output in subroutines. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
ITP: iep -- Interactive Editor for Python
Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name: iep Version : 3.5 Upstream Author : Almar Klein * URL : http://www.iep-project.org/ * License : BSD Programming Lang: Python Description : Interactive Editor for Python Description: IEP is a cross-platform Python IDE aimed at interactivity and introspection. Its practical design is aimed at simplicity and efficiency. IEP consists of an editor, a shell, and a set of tools to help the programmer in various ways. Further information: - IEP is similar to Spyder but comparatively much lighter, - Supports additional features useful for development, like a source tree, builtin loggin, cell support... - One of the package dependency is not (yet) in Debian: pyzolib, - Pyzolib is also licensed under the BSD license. I believe this package is a good candidate for inclusion to the Debian science family, via the Sponsorship of Blends initiative [1]. [1] https://wiki.debian.org/DebianPureBlends/SoB Cheers, Ghislain
Re: Announcing a Debian Hamradio Blend
On 2014-12-11 12:39, Iain R. Learmonth wrote: [Forwarding to d-d-a on behalf of Iain since he can not sign as DD] I suspect you forwarded the wrong mail, was it meant to be an announcement from Iain about the blend as the subject line implies? -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 i have six years of solaris sysadmin experience, from 8->10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/361171ec25f65a2699c3564959baa...@hogwarts.powdarrmonkey.net
Re: Bug#772736: ITP: pathlib -- Set of classes to handle filesystem paths
Hi, Am Mittwoch, den 10.12.2014, 17:17 +0100 schrieb Frank Brehm: > Package: wnpp > Severity: wishlist > Owner: Frank Brehm > > * Package name: pathlib > Version : 1.0.1 > Upstream Author : Antoine Pitrou > * URL : https://pypi.python.org/pypi/pathlib > * License : MIT Licence > Programming Lang: Python > Description : Set of classes to handle filesystem paths this should probably be called python-pathlib, shan’t it? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Bug#772736: ITP: pathlib -- Set of classes to handle filesystem paths
Am Donnerstag, den 11.12.2014, 14:35 +0100 schrieb Joachim Breitner: > Hi, > > > Am Mittwoch, den 10.12.2014, 17:17 +0100 schrieb Frank Brehm: > > Package: wnpp > > Severity: wishlist > > Owner: Frank Brehm > > > > * Package name: pathlib > > Version : 1.0.1 > > Upstream Author : Antoine Pitrou > > * URL : https://pypi.python.org/pypi/pathlib > > * License : MIT Licence > > Programming Lang: Python > > Description : Set of classes to handle filesystem paths > > > this should probably be called python-pathlib, shan’t it? The source is called pathlib, but the binary packages are called python-pathlib and python-pathlib-doc. -- Benjamin Drung System Developer ProfitBricks GmbH - The IaaS-Company Greifswalder Str. 207 D - 10405 Berlin Mail: benjamin.dr...@profitbricks.com Fax: +49 30 577 008 598 URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506 B. Geschäftsführer: Andreas Gauger, Achim Weiss. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1418305659.4914.8.ca...@profitbricks.com
Weird wrong email (Was: Re: Announcing a Debian Hamradio Blend)
On Thu, Dec 11, 2014 at 01:39:29PM +0100, Iain R. Learmonth wrote: > [Forwarding to d-d-a on behalf of Iain since he can not sign as DD] This seems to be the wrong sort of email to forward to d-d-a. (Note: I'm not subscribed to -devel, so CC me on a reply). > > Ian R Leamonth, > > In Debian GNU/linux they NEVER discussed to port other packages, infact in > different situations i discuss this on debian-hamradio and on #fsf where > they said that there was not any necessity to port the packages, and that > is left to the user the freedom, to take the packages in source code, from > third parties, to build it, and to use it. > > I said: "if a user don't find a package in the mirrors, he think that does > not exist", but they prefeer to ignore what i said, belittling what i said > to them. > > A day i decided to power on my Kenwood TM-255E, i was on 145.750 -600Khz, > and while i was taking my shower, i listened a radioamateur, which discuss > with another one, about the fact that on GNU/linux are not available > enough packages for hamradio. > > I finished to take my shower, and again wet, i asked to break the > communication, i said my callsign: iw0fzw, my name: paolo and my locator: > jn61fu, and spoke, about the fact that there are 330 packages to port, and > not again ported on the mirrors, now, Debian Community, all of a sudden > wake up, and decides to port the packages. > > So is very easy, and don't mention who said them to do this. > > Awaiting for your reply, > > 73 paolo iw0fzw > > p.s: is very easy to ignore, what say the other people, so that they can > take all the credits. > > to show that they are saying the false, here i upload as attachment the > file hamradio > > i asked too support to my friend Danilo to package all the sowfatware > availbale only as source code on third parties. > > I should now take me for a ride by those of Debian? > > how you would feel to be taken for a ride by some people? > > -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Be friendly, do not top-post, and follow RFC 1855 "Netiquette". - If you don't I might ignore you. pgpOiIlxd8w5R.pgp Description: PGP signature
Re: Announcing a Debian Hamradio Blend
Hi, > [Forwarding to d-d-a on behalf of Iain since he can not sign as DD] The quoted message was addressed *to* Iain and didn't make much sense to me. Isn't this the announcement here? https://lists.debian.org/debian-blends/2014/12/msg0.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141211140833.ga5...@squeeze.pyro.eu.org
ITP: pyzolib -- Utilities for the Pyzo environment
Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name: pyzolib Version : 0.3.3 Upstream Author : Almar Klein * URL : https://bitbucket.org/pyzo/pyzolib * License : BSD Programming Lang: Python Description : Utilities for the Pyzo environment Description The pyzolib package provides basic functionality for the Pyzo environment. It contains a collection of modules and small packages that should be imported as "from pyzolib import xxx" . The packages currently are: * path - object oriented path processing (no more os.path.x) * paths - Get paths to useful directories in a cross platform manner. * qt - Proxy for importing QtCore et al. from PySide or PyQt4 * ssdf - the Simple Structured Data Format (for config files and scientific databases) * insertdocs - a sphynx pre-processor to include docstrings in the text, allowing readthedocs.org to host the docs without requiring importing code. * pyximport - for easy on the fly compilation of Cython, using the Pyzo environment to establish the location of a gcc compiler. * gccutils - used by the above to manage the gcc compiler. * interprerers - list the Python interpreters available on this system. * dllutils - utilities to set the RPATH in dynamic libararies and remove depndencies on the MSVCR from the embedded manifest. Further information: - Pyzolib is a dependency to iep [1], - Pyzolib has already been reviewed and packaged in Fedora [2]. I'd suggest to maintain this package as part of the Debian Science family, together with IEP. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23772820 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1064661 Cheers, Ghislain
Bug#772827: ITP: kerneloops -- kernel oops tracker
Package: wnpp Owner: Balint Reczey Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: kerneloops Version : 0.12+git20140509-1 Upstream Author : Arjan van de Ven * URL : https://github.com/oops-kernel-org/kerneloops * License : GPL-2 Programming Lang: C Description : kernel oops tracker kerneloops is a daemon that collects kernel crash information and then submits the extracted signature to the kerneloops.org website for statistical analysis and presentation to the Linux kernel developers. -- I would like to reintroduce the package into Debian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5489a860.3030...@balintreczey.hu
Re: credentials config at pkg install
Thanks for quick replies! I'll go forward with AICCU and debconf way. Not sure if I will eventually upload my package to Debian though, since this dynDNS provider is only for Finland and user base would be small. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAPqGMfJB3qkcy8j7Ub+ae3=oi0cujzzxedvzb0bdrfjjqwa...@mail.gmail.com
Can/should we have an efi/efi-any platform architecture?
When working on UEFI kernel support, for both armhf and arm64, we came across packages (in several distributions) that were manually set to build for architectures where UEFI was available - and so would not be built for the ARM architectures. These are some obvious utilites such as: - efibootmgr - efivar/libefivar - future versions of gnu-efi (upstream support for arm* has not trickled back down yet) But also installer-specific ones like: - partman-efi And some weakly related-to, but not really part of: - dmidecode ... and definitely other ones I haven't come across yet. The point is, when we add support for another architecture which supports UEFI, there are a number of packages that you will want to enable for that architecture. Currently, this means trawling through all of the packages and explicitly adding entries for If we could transition this to be able to specify efi-all (or whatever) instead of an explicit list of certain architectures, this would be a lot more straightforward operation. Most, if not all, of these tools use only standard posix interfaces, so will build cleanly for any architecture. An alternative would of course be to simply do like with acpica-tools, and build all of these tools for all architectures. The problem there would be with packages which depend on packages that only exist on architectures that have UEFI - i.e. partman-efi vs. efi-modules. Would this be useful, desirable, an accident waiting to happen? / Leif -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141211180858.gs2...@bivouac.eciton.net
Re: Can/should we have an efi/efi-any platform architecture?
Hi Leif, On 11.12.2014 19:08, Leif Lindholm wrote: > If we could transition this to be able to specify efi-all (or > whatever) instead of an explicit list of certain architectures, this > would be a lot more straightforward operation. > Would this be useful, desirable, an accident waiting to happen? Useful, possibly, but there is no mechanism that could be used or recycled for that, so it would be an entirely new mechanism in the package management framework, with a fairly limited use case. As this is something that changes rather seldom, I think it would be overkill. Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5489e423.8090...@debian.org
debian-efi mailing list
Hi folks, I'm thinking it might be useful to set up a specific debian-efi mailing list to help as a central space for discussion about (U)EFI issues and support in Debian. There's been quite a lot of development in this area recently, and (as Leif just mentioned on -devel) there are a number of packages that might benefit from wider discussion and (maybe?) group maintenance. We could also help out with targeted support for users with EFI-related problems. So, pursuant to the HOWTO [1], I'm asking here who else might be interested in using such a list. Please follow up here and we'll see how far we get. [1] https://www.debian.org/MailingLists/HOWTO_start_list -- 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: https://lists.debian.org/20141211190034.ga31...@einval.com
Re: Can/should we have an efi/efi-any platform architecture?
Simon Richter wrote: >Hi Leif, > >On 11.12.2014 19:08, Leif Lindholm wrote: > >> If we could transition this to be able to specify efi-all (or >> whatever) instead of an explicit list of certain architectures, this >> would be a lot more straightforward operation. > >> Would this be useful, desirable, an accident waiting to happen? > >Useful, possibly, but there is no mechanism that could be used or >recycled for that, so it would be an entirely new mechanism in the >package management framework, with a fairly limited use case. > >As this is something that changes rather seldom, I think it would be >overkill. Hmmm, maybe. EFI is a bit of a special case in several respects - in some places in Debian (e.g. d-i) it's treated like a sub-architecture. But it's a common sub-architecture across several architectures, which is very different to m68k/atari and the like. On a related front... see other mail. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xz8pq-0004t6...@mail.einval.com
Re: Can/should we have an efi/efi-any platform architecture?
Quoting Simon Richter (2014-12-11 19:36:19) > On 11.12.2014 19:08, Leif Lindholm wrote: > >> If we could transition this to be able to specify efi-all (or >> whatever) instead of an explicit list of certain architectures, this >> would be a lot more straightforward operation. > >> Would this be useful, desirable, an accident waiting to happen? > > Useful, possibly, but there is no mechanism that could be used or > recycled for that, so it would be an entirely new mechanism in the > package management framework, with a fairly limited use case. > > As this is something that changes rather seldom, I think it would be > overkill. Perhaps if framing it more generally instead, it would be relevant to work on. How about a control file hint "Arch-Varying:" listing features known to be "crippled" for some of the archs they are actually compiled on? Example that popped up recentently is VLC which upstream supports OSS as fallback for ALSA, and (as I understand it) for Debian is built _without_ support for OSS on Linux archs where ALSA is generally (but possibly not for all use cases) superior. I imagine vlc could be tagged as "Arch-Varying: alsa oss" ...where the "alsa" hint can be expected for any package supporting alsa but working to some degree without it, whereas the "oss" hint for some would be a reason to inspect closer (e.g. check README file for details). To minimize creativity in feature naming we could put names up on a wiki page, and later if/when gaining traction move that to Policy. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Can/should we have an efi/efi-any platform architecture?
On Thu, 11 Dec 2014 19:36:19 +0100 Simon Richter wrote: > Hi Leif, > > On 11.12.2014 19:08, Leif Lindholm wrote: > > > If we could transition this to be able to specify efi-all (or > > whatever) instead of an explicit list of certain architectures, this > > would be a lot more straightforward operation. > > > Would this be useful, desirable, an accident waiting to happen? > > Useful, possibly, but there is no mechanism that could be used or > recycled for that, so it would be an entirely new mechanism in the > package management framework, with a fairly limited use case. There is an accepted mechanism: linux-any is a group of architectures which have one set of packages in common and we have had others. efi-any would seem to be entirely possible without implementing something completely new. It would need dpkg and buildd support. With linux-any it relies on a list of architectures in a table in dpkg - the same could be done for other groups. The mechanisms exist, the question is how many other variants would be created by adopting this? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpaT0kgbPNR0.pgp Description: OpenPGP digital signature
Re: Can/should we have an efi/efi-any platform architecture?
Hi, On Thu, Dec 11, 2014 at 06:08:58PM +, Leif Lindholm wrote: > When working on UEFI kernel support, for both armhf and arm64, we came > across packages (in several distributions) that were manually set to > build for architectures where UEFI was available - and so would not be > built for the ARM architectures. > > These are some obvious utilites such as: > - efibootmgr > - efivar/libefivar > - future versions of gnu-efi (upstream support for arm* has not > trickled back down yet) > > But also installer-specific ones like: > - partman-efi > > And some weakly related-to, but not really part of: > - dmidecode > > ... and definitely other ones I haven't come across yet. > > The point is, when we add support for another architecture which > supports UEFI, there are a number of packages that you will want to > enable for that architecture. Currently, this means trawling through > all of the packages and explicitly adding entries for > If we could transition this to be able to specify efi-all (or > whatever) instead of an explicit list of certain architectures, this > would be a lot more straightforward operation. > > Most, if not all, of these tools use only standard posix interfaces, > so will build cleanly for any architecture. > > An alternative would of course be to simply do like with acpica-tools, > and build all of these tools for all architectures. The problem there > would be with packages which depend on packages that only exist on > architectures that have UEFI - i.e. partman-efi vs. efi-modules. > > Would this be useful, desirable, an accident waiting to happen? How about building for "arch: any" and adding a build dependency on a new "efi-support" package, that is only available for architectures with efi available? -- Sebastian signature.asc Description: Digital signature
Re: Can/should we have an efi/efi-any platform architecture?
Quoting Neil Williams (2014-12-11 21:07:15) > On Thu, 11 Dec 2014 19:36:19 +0100 > Simon Richter wrote: >> On 11.12.2014 19:08, Leif Lindholm wrote: >> >>> If we could transition this to be able to specify efi-all (or >>> whatever) instead of an explicit list of certain architectures, this >>> would be a lot more straightforward operation. >> >>> Would this be useful, desirable, an accident waiting to happen? >> >> Useful, possibly, but there is no mechanism that could be used or >> recycled for that, so it would be an entirely new mechanism in the >> package management framework, with a fairly limited use case. > > There is an accepted mechanism: linux-any is a group of architectures > which have one set of packages in common and we have had others. > efi-any would seem to be entirely possible without implementing > something completely new. It would need dpkg and buildd support. With > linux-any it relies on a list of architectures in a table in dpkg - > the same could be done for other groups. Elegant! > The mechanisms exist, the question is how many other variants would be > created by adopting this? Please ignore my use cases - they were about features enabled/disabled rather than architectures targeted at all, which is what Leif asks for. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Can/should we have an efi/efi-any platform architecture?
On 11/12/14 18:08, Leif Lindholm wrote: > The point is, when we add support for another architecture which > supports UEFI, there are a number of packages that you will want to > enable for that architecture. I've occasionally wished we had a way to make a requiring package conditionally built depending on availability of another package, usually an interpreter that needs explicit porting. For instance: * dbus should ideally Build-Depends: valgrind on precisely those architectures where valgrind exists * C# bindings should ideally be built on precisely those architectures where mono exists * Java bindings should ideally be built on precisely those architectures where openjdk exists At a source package granularity, you can fake it by having a (possibly spurious) Build-Depends on the required package, which will put the requiring package in BD-Uninstallable state (e.g. https://buildd.debian.org/status/package.php?p=gtk-sharp3 explains why gtk-sharp3 isn't built on mips, which doesn't have mono). That doesn't work for individual binary packages unless you hard-code architecture lists, though (e.g. a C library with an optional Java or C# binding would need to hard-code the Java/C# architectures). Perhaps this could be a build-profile? Source: dbus Build-Depends: ..., valgrind-dev , ... Source: libfoo ... Package: libfoo-sharp Architecture: any Build-Profiles: Maybe we could even use package names as the features, so each feature in the archfeature namespace is automatically said to be available iff the package exists in apt? That covers the common "interpreter that needs porting" case, although I don't know whether there's anything like an efi-dev that could act as the "flag" for EFI architectures. Other possible colours for this bike shed include pkgexists.valgrind, with.valgrind, or (with the opposite sense) without.valgrind, missing.valgrind. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548a0373.2030...@debian.org
Re: Can/should we have an efi/efi-any platform architecture?
On 11 December 2014 at 20:07, Neil Williams wrote: > On Thu, 11 Dec 2014 19:36:19 +0100 > Simon Richter wrote: > >> Hi Leif, >> >> On 11.12.2014 19:08, Leif Lindholm wrote: >> >> > If we could transition this to be able to specify efi-all (or >> > whatever) instead of an explicit list of certain architectures, this >> > would be a lot more straightforward operation. >> >> > Would this be useful, desirable, an accident waiting to happen? >> >> Useful, possibly, but there is no mechanism that could be used or >> recycled for that, so it would be an entirely new mechanism in the >> package management framework, with a fairly limited use case. > > There is an accepted mechanism: linux-any is a group of architectures > which have one set of packages in common and we have had others. > efi-any would seem to be entirely possible without implementing > something completely new. It would need dpkg and buildd support. With > linux-any it relies on a list of architectures in a table in dpkg - the > same could be done for other groups. > > The mechanisms exist, the question is how many other variants would be > created by adopting this? > And it will require a long time to be used. Imho this smells more like a build profile e.g. BuildDepends: does-not-implement-efi That way on non-efi implementing architectures the package will get stuck in a dep-wait state. However, EFI is not that simple as it has it's own architecture mapping, it's own binary format and execution environment, but it is unlikely that we will see debian ported to be run in pure EFI environment. EFI is currently defined for IA32, X64, IA64, ARM, and AA64. However in practice the support implementing it is ahead on X64 (despite IA64 being the first one). E.g. even things like edk2 - i've tried to compile it for IA32 but appears to be only partially implemented for gcc toolchain. Thus even if something is "efi-ish" and should build for all "efi-like-arches" it doesn't mean that it was ported or builds with efi toolchain. For some of these things we are stepping into crazy land of ia32-libs territory where we are considering to introduce and install grub-ia32 & grub-x64 on amd64 systems. IMHO it would be cool to compile gnu-efi, grub, etc as gnu-efi:efi-ia32, gnu-efi:efi-x64 etc. packages and have generic mapping somewhere between debian architectures & efi architectures and install those things as appropriate. That would be a partial arch. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhlugatff2szaxd+m8nk-k0tb-t7jhhfmickgrcuj_is8...@mail.gmail.com
Re: Bug#772736: ITP: pathlib -- Set of classes to handle filesystem paths
Benjamin Drung writes: > The source is called pathlib, but the binary packages are called > python-pathlib and python-pathlib-doc. Even for the source package name, “pathlib” is IMO too general. This is specifically a library for Python programmers only; its source package name should not grab a generic name like “pathlib”. -- \ “The long-term solution to mountains of waste is not more | `\ landfill sites but fewer shopping centres.” —Clive Hamilton, | _o__)_Affluenza_, 2005 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85388lhnsk@benfinney.id.au
Work-needing packages report for Dec 12, 2014
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. Total number of orphaned packages: 656 (new: 4) Total number of packages offered up for adoption: 145 (new: 0) Total number of packages requested help for: 57 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: fig2ps (#772449), orphaned 4 days ago Description: Converts xfig files into ps, eps or pdf files using LaTeX for processing text Installations reported by Popcon: 538 haskell-doc (#772423), orphaned 5 days ago Description: Assorted Haskell language documentation Installations reported by Popcon: 415 haskell98-tutorial (#772424), orphaned 5 days ago Description: A Gentle Introduction to Haskell 98 Reverse Depends: haskell-doc Installations reported by Popcon: 435 libjna-posix-java (#772579), orphaned 3 days ago Description: basic POSIX-like functions for Java Installations reported by Popcon: 187 652 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 145 packages are awaiting adoption. See http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 1774 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache goplay packagesearch Installations reported by Popcon: 75787 athcool (#278442), requested 3698 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 39 awstats (#755797), requested 141 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4165 balsa (#642906), requested 1173 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 739 cardstories (#624100), requested 1326 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 9 chromium-browser (#583826), requested 1656 days ago Description: Chromium browser Reverse Depends: chromedriver chromium-dbg chromium-l10n design-desktop-web mozplugger Installations reported by Popcon: 25688 cups (#532097), requested 2014 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-core-drivers (64 more omitted) Installations reported by Popcon: 142688 debtags (#567954), requested 1774 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2301 developers-reference (#759995), requested 103 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 15207 ejabberd (#767874), requested 38 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib Installations reported by Popcon: 859 fbcat (#565156), requested 1793 days ago Description: framebuffer grabber Installations reported by Popcon: 164 freeipmi (#628062), requested 1295 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools libfreeipmi-dev libfreeipmi16 libipmiconsole-dev libipmiconsole2 libipmidetect-dev (4 more omitted) Installations reported by Popcon: 5911 gnat-gps (#496905), requested 2296 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 511 gnokii (#677750), requested 908 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6 xgnokii Installations reported by Popcon: 1543 gnupg (#660685), requested 1025 days ago Description: GNU privacy guard - a free PGP replacement Reverse Depends: 0install-core apt aptly arriero bootstrap-base cdebootstrap cdebootstrap-static clamav-unofficial-sigs cloud-utils debbindiff (58 more omitted) Installations reported by Popcon: 1727
Re: debian-efi mailing list
El 11/12/14 a las 16:00, Steve McIntyre escibió: > Hi folks, > > I'm thinking it might be useful to set up a specific debian-efi > mailing list to help as a central space for discussion about (U)EFI > issues and support in Debian. > > There's been quite a lot of development in this area recently, and (as > Leif just mentioned on -devel) there are a number of packages that > might benefit from wider discussion and (maybe?) group maintenance. We > could also help out with targeted support for users with EFI-related > problems. > > So, pursuant to the HOWTO [1], I'm asking here who else might be > interested in using such a list. Please follow up here and we'll see > how far we get. > > [1] https://www.debian.org/MailingLists/HOWTO_start_list > +1 -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548a3b91.5060...@docksud.com.ar
Re: Bug#772736: ITP: pathlib -- Set of classes to handle filesystem paths
On Dec 12, 2014, at 08:36 AM, Ben Finney wrote: >Even for the source package name, “pathlib” is IMO too general. This is >specifically a library for Python programmers only; its source package >name should not grab a generic name like “pathlib”. Why not first-come-first-served? Cheers, -Barry pgpgKr8SfmhUi.pgp Description: OpenPGP digital signature
Re: debian-efi mailing list
I'm interested in EFI, and therefore in debian-efi. David Coe +1 410 489 9521 On Thu, Dec 11, 2014 at 7:49 PM, Fernando Toledo wrote: > El 11/12/14 a las 16:00, Steve McIntyre escibió: > > Hi folks, > > > > I'm thinking it might be useful to set up a specific debian-efi > > mailing list to help as a central space for discussion about (U)EFI > > issues and support in Debian. > > > > There's been quite a lot of development in this area recently, and (as > > Leif just mentioned on -devel) there are a number of packages that > > might benefit from wider discussion and (maybe?) group maintenance. We > > could also help out with targeted support for users with EFI-related > > problems. > > > > So, pursuant to the HOWTO [1], I'm asking here who else might be > > interested in using such a list. Please follow up here and we'll see > > how far we get. > > > > [1] https://www.debian.org/MailingLists/HOWTO_start_list > > > +1 > > -- > Fernando Toledo > Dock Sud BBS > http://bbs.docksud.com.ar > telnet://bbs.docksud.com.ar > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/548a3b91.5060...@docksud.com.ar > >
Linux Kernel 3.17 Features
Hello, I am aware that Debian Jessie will be using Linux Kernel 3.16, however I was wondering if there is a possibility of Jessie including some of the features added in 3.17 such as: getrandom(), support for Acer C720, and support for Broadwell audio. getrandom() commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6e9d6f38894798696f23c8084ca7edbf16ee895 Acer C720 commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=da3b0ab75aadab63d1ffd5563100c9386e444dad Broadwell commit: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=afdb74fd708fb4330485212f76a70b91967b1f70 Thanks, Benjamin
Re: Bug#772736: ITP: pathlib -- Set of classes to handle filesystem paths
On Thursday, December 11, 2014 09:23:36 PM Barry Warsaw wrote: > On Dec 12, 2014, at 08:36 AM, Ben Finney wrote: > >Even for the source package name, “pathlib” is IMO too general. This is > >specifically a library for Python programmers only; its source package > >name should not grab a generic name like “pathlib”. > > Why not first-come-first-served? If it's not for general use, a package name that sounds like it is would be potentially confusing. If it doesn't ship a python module/extension (in which case python-pathlib would be great, since that's what you should call the binary), then pathlib- python would also work. Scott K signature.asc Description: This is a digitally signed message part.
Re: Linux Kernel 3.17 Features
On Thu, 2014-12-11 at 21:08 -0600, Benjamin Przybocki wrote: > Hello, > I am aware that Debian Jessie will be using Linux Kernel 3.16, however > I was wondering if there is a possibility of Jessie including some of > the features added in 3.17 such as: getrandom(), support for Acer > C720, and support for Broadwell audio. > > > getrandom() > commit: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6e9d6f38894798696f23c8084ca7edbf16ee895 No. > Acer C720 > commit: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=da3b0ab75aadab63d1ffd5563100c9386e444dad Maybe. > Broadwell > commit: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=afdb74fd708fb4330485212f76a70b91967b1f70 Maybe. (But that's just audio.) Please open bugs against src:linux for the hardware support. Ben. -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens' signature.asc Description: This is a digitally signed message part
Bug#772908: ITP: pysph -- Open source framework for Smoothed Particle Hydrodynamics
Package: wnpp Severity: wishlist Owner: Anton Gladky * Package name: pysph * URL : http://pysph.googlecode.com * License : BSD Programming Lang: Python Description : Open source framework for Smoothed Particle Hydrodynamics open source framework for Smoothed Particle Hydrodynamics It is implemented in Python and the performance critical parts are implemented in Cython. . PySPH is implemented in a way that allows a user to specify the entire SPH simulation in pure Python. High-performance code is generated from this high-level Python code, compiled on the fly and executed. PySPH also features optional automatic parallelization using mpi4py and Zoltan. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141212052007.26135.46443.reportbug@debian
