Re: Facilitating external repositories
So, I've been giving this some more thought, and have tried to write a spec, but then found that... On Sat, Jun 13, 2015 at 05:03:15PM +0800, Paul Wise wrote: > https://lists.debian.org/deity/2014/01/msg00055.html ...this (and the discussion following it) actually seems fairly close to what my spec was going to be. I would suggest that the deb822 sources.list format be slightly extended so that: - Apt will try to download it from a default location in the repository (or perhaps a location specified in the deb822 sources.list file itself). - It may be GPG-signed by one or more keys. Apt should have a way of configuring GPG keys that may be allowed to sign sources.list files, preloaded with the set of keys in the Debian keyring. This will allow system administrators in large environments to specify their own set of keys allowed to sign repositories, as well as allowing downstreams to add its own ways of trusting repositories. - It may possibly add a limitation on the packages that can be downloaded from the given repository (so that a package repository cannot suddenly acquire a package "libc6", accidentally or otherwise). This should allow for wildcards (e.g., in my specific situation this field would contain "libbeid*, eid-*, beid-*") - (It would be good if apt also added the ability to limit keys on a per-repository basis, already suggested in the January 2014 discussion but not yet implemented due to missing required infrastructure) We could then also add a field "Default-Install:", ignored by apt but honoured by a handler for the MIME type of sources.list files, that would list a set of packages to install by default when adding this repository. Added together, this would give maintainers of third-party repositories the following: - A trusted path from Debian to their repository; - Insurance (when the sources.list file is signed by multiple keys) against a DD leaving the project, or their key being compromised, or similar; - A way for their users to install the software they're using by clicking on a link (to the sources.list file, passed on to this MIME type handler) which automatically (after appropriate authentication and confirmation) adds the file to sources.list, runs "apt-get update", and installs a default set of packages from this repository. At the same time, it would allow us to limit the possible "damage" third-party repositories can do in several ways: - Limit the keys with which they can sign their repositories; - Limit the packages they can override, very much in the same way we limit DMs today; - If the Pin-Priority: field as proposed by aj is implemented (doesn't appear to be the case today), limit the impact the repository can have. Of course, the above may or may not be appropriate in some cases, so I'm not suggesting we make any of those fields mandatory; it should be up to the DD signing the sources.list configuration file to ensure that the contents of that file is sane and safe. Thoughts? -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: Packaging ASL
On 21/07/15 18:17, Zeev Pekar wrote: [...] May I ask somebody to volunteer to finish the initial creation of the package, so it can be uploaded? It has been developed/tested on Debian since 2010 so the process should be smooth. Packaging efforts for other distros are underway and probably can be helpful for Debian [1]. Thank you, Zeev -- In short about the library: It is an OpenCL-based multiphysics simulation software that can be deployed (besides CPU) on different massively parallel architectures like GPUs, FPGAs, DSPs etc. and covers a variety of physical and chemical phenomena. It can be utilized in a number of fields: - CFD: http://asl.org.il/benchmarks/multicomponent_flow/ - image-guided surgery: http://avtechscientific.com/cryovision - crystal growth: https://github.com/AvtechScientific/ASL/blob/master/examples/levelSet/levelSetFacetedGrowth.cc - virtual sensing (i.a. medical): http://avtechscientific.com/brainshift - R&D of biomed devices (i.a. microfluidics): http://avtechscientific.com/focus - etc., etc.. -- [1]: https://aur.archlinux.org/packages/libasl/ https://copr.fedoraproject.org/coprs/lupinix/ASL/ https://build.opensuse.org/package/show/home:ealin:physics/ASL [...] I am fairly experienced with packaging CMake-based projects and could give you a hand on that. Since the project follows a Git workflow (master branch + tagged release), it would make sense to adopt a Git approach for the packaging repository rather than the more conventional import-from-source-tarball approach that the d-science policy only advocates. I can see from your original work that you are not quite there yet with the packaging content, which is what Andreas mentioned in his reply. I am afraid that the "New maintainers guide" is a mandatory stop, should you intend to maintain this package long term in Debian. I can only give you a lift for the initial effort. Best regards, Ghislain Hi Ghislain, initial effort, i.e. initial package creation is exactly what is needed - Anton will take over the upload and the maintenance (at least in the short term). It was not my intention to maintain ASL in Debian - I take care of it upstream (I'm one of the developers). I wanted to do my best to initiate the process. I hope that there will be more people interested in maintaining the package once it actually enters Debian and Ubuntu (btw. is there a chance it will get into the Ubuntu 15.10?) and the community starts to grow. Thank you very much! Zeev From the first look I have had of it, it should not be too complicated to put some packaging up to shape. FYI, I filed a bug with regards to a missing copyright header caught by licensecheck. I can't commit to a particular timeline. It will probably take me a few commutes to work before getting something decent. As to whether it will land in 15.10 or not, that will depend on how quickly the package is mentored (via Andreas or Anton maybe?) and eventually processed by the release team. If the package does not land in time for 15.10, you guys can still make a PPA available on Launchpad and use backportpackage from the Debian source package to generate Ubuntu packages for all versions you guys want to support (maybe all the way down to 14.04 LTS, assuming all build-deps are in there). Hope that makes sense. Cheers, Ghis -- 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/55b0bd46.4070...@gmail.com
Re: Facilitating external repositories
Wouter Verhelst writes ("Re: Facilitating external repositories"):
> - It may be GPG-signed by one or more keys. Apt should have a way of
> configuring GPG keys that may be allowed to sign sources.list files,
> preloaded with the set of keys in the Debian keyring. This will allow
> system administrators in large environments to specify their own set
> of keys allowed to sign repositories, as well as allowing downstreams
> to add its own ways of trusting repositories.
The /name/ of the external repository should also be covered by the
signature.
Ian.
--
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/21936.55299.724772.736...@chiark.greenend.org.uk
Re: Ad-hoc survey of existing Debian git integration tools
On Tue, 21 Jul 2015 18:46:47 +0100, Ian Jackson wrote:
> Thorsten Glaser writes ("Re: Ad-hoc survey of existing Debian git
> integration tools"):
>> [workflow description]
>
> Thanks. FYI, dgit trees are (for `3.0 (quilt)' format source packages)
> what is nowadays called a `patches-applied packaging branch'.
>
> That is, the dgit git tree contains the patches in debian/patches/ but
> also contains the implied changes in the main source code. If you add
> commits yourself to the dgit git tip, new patches will generated from
> your commits.
Does that mean that if I fix or refresh a patch then my quilt series will
contain the original and the fixup as patches?
--
Saludos,
Felipe Sateler
--
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/moqmt4$j22$1...@ger.gmane.org
Bug#793392: ITP: dcmtkpp -- Wrappers around DCMTK to have an easier API
Package: wnpp Severity: wishlist Owner: Debian Med team * Package name: dcmtkpp Version : 0.2.1 Upstream Author : Julien Lamy * URL : https://github.com/lamyj/dcmtkpp * License : CeCILL-B Programming Lang: C++ Description : Wrappers around DCMTK to have an easier API DCMTK++ is a set of wrappers around DCMTK, leveraging C++ constructs to have an easier API, notably for the networking part. Included are exception-based error handling, generic access to datasets elements, standard JSON representation of datasets, explicit messages and generic implementation of SCU and SCP. -- 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/20150723152745.19516.74708.reportbug@jessie-amd64
Bug#793393: ITP: lttnganalyses -- LTTng 2.0 trace analysis tools
Package: wnpp Severity: wishlist Owner: Michael Jeanson * Package name: lttnganalyses Version : 0.3.0 Upstream Author : Julien Desfossez * URL : https://github.com/lttng/lttng-analyses * License : MIT Programming Lang: Python Description : LTTng 2.0 trace analysis tools The LTTng project aims at providing highly efficient tracing tools for Linux. Its tracers help tracking down performance issues and debugging problems involving multiple concurrent processes and threads. Tracing across multiple systems is also possible. . This package contains various tools to analyse LTTng kernel traces and extract monitoring data and metrics. As opposed to other diagnostic or monitoring solutions, this approach is designed to allow users to record their system's activity with a low overhead, wait for a problem to occur and then diagnose its cause offline. -- 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/20150723153014.652.16068.report...@sid1.lan
Bug#793395: ITP: binplist -- binary property list parser module
Control: block 792335 by -1 Package: wnpp Owner: Hilko Bengen Severity: wishlist * Package name: binplist Version : 0.1.5 Upstream Author : Google Inc * URL or Web page : https://github.com/libyal/binplist * License : Apache-2.0 Description : binary property list parser module binplist is a dependency for Plaso. -- 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/87egjy50zr@msgid.hilluzination.de
Re: Facilitating external repositories
On Thu, Jul 23, 2015 at 01:03:15PM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Re: Facilitating external repositories"):
> > - It may be GPG-signed by one or more keys. Apt should have a way of
> > configuring GPG keys that may be allowed to sign sources.list files,
> > preloaded with the set of keys in the Debian keyring. This will allow
> > system administrators in large environments to specify their own set
> > of keys allowed to sign repositories, as well as allowing downstreams
> > to add its own ways of trusting repositories.
>
> The /name/ of the external repository should also be covered by the
> signature.
What would you describe as the "name" of the repository?
The URL is already part of the sources.list file. Additionally, the deb822 form
of the sources.list file is already configured to have a short and long
Description: field.
Am I missing something?
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
--
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/20150723173947.gb2...@grep.be
Bug#793404: massive waste of CPU time in debian/rules by inline commands
Package: general Severity: minor Hello Fellow Maintainers, please tell me that I am wrong or that I start fighting the windmills if that's the case, but I have a general impression that something smells in lots of debian/rules files nowadays and we need a concept to improve that. The problem: I see lots of $(shell ...) stuff. In boost, there are about 12 such calls. And they run dpkg-architecture or dpkg-parsechangelogs or similar commands. When this was done a just couple of times (i.e. before dh(7)), that's acceptable. But now, it looks like debian/rules is called many, many times through dh. Making many, many calls of that inline commands. Wasting many, many CPU cycles. All that just to retrieve the same information all over again. In the emulated m68k environment, it spends about half an hour (guessed, not measured) before starting the actual build, doing things like: | \_ /usr/bin/perl -w /usr/bin/dh build --with python2 --with python3 | \_ /usr/bin/make -f debian/rules override_dh_auto_configure | \_ /bin/sh -c dpkg-parsechangelog | grep Version | cut -d' ' -f2 | \_ /usr/bin/perl /usr/bin/dpkg-parsechangelog | | \_ /usr/bin/perl /usr/lib/dpkg/parsechangelog/debian -ldebian/changelog --file debia I think we need to find a shortcut for this. The best idea I got after short brainstorming is hacking fakeroot to provide a cache of stdout data from certain commands. If someone has a better idea or could point to an existing concept or implementation, please tell me. Regards, Eduard. -- 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/20150723174346.ga28...@rotes76.wohnheim.uni-kl.de
Bug#793404: massive waste of CPU time in debian/rules by inline commands
Quoting Eduard Bloch (2015-07-23 19:43:46) > The problem: I see lots of $(shell ...) stuff [in debian/rules files]. > In boost, there are about 12 such calls. And they run > dpkg-architecture or dpkg-parsechangelogs or similar commands. debian/rules is a make file. In the make language, variables can be expanded either immediately (similar to shell) or when used. This is expensive (when used multiple times as is the case with Boost): pyversions = $(shell pyversions -rv) $(shell py3versions -rv) Changing to early expanded saves CPU cycles: pyversions := $(shell pyversions -rv) $(shell py3versions -rv) Hope that helps, - 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
Bug#793404: massive waste of CPU time in debian/rules by inline commands
On Thu, 23 Jul 2015 19:43:46 +0200 Eduard Bloch wrote: > please tell me that I am wrong or that I start fighting the windmills if > that's the case, but I have a general impression that something smells > in lots of debian/rules files nowadays and we need a concept to improve > that. > > The problem: I see lots of $(shell ...) stuff. In boost, there are about > 12 such calls. And they run dpkg-architecture or dpkg-parsechangelogs or > similar commands. When this was done a just couple of times (i.e. before > dh(7)), that's acceptable. But now, it looks like debian/rules is called > many, many times through dh. Making many, many calls of that inline > commands. Wasting many, many CPU cycles. All that just to retrieve the > same information all over again. > > In the emulated m68k environment, it spends about half an hour (guessed, > not measured) before starting the actual build, doing things like: > > | \_ /usr/bin/perl -w /usr/bin/dh build --with python2 --with python3 > | \_ /usr/bin/make -f debian/rules override_dh_auto_configure > | \_ /bin/sh -c dpkg-parsechangelog | grep Version | cut -d' ' > -f2 > | \_ /usr/bin/perl /usr/bin/dpkg-parsechangelog > | | \_ /usr/bin/perl /usr/lib/dpkg/parsechangelog/debian > -ldebian/changelog --file debia I think you're right. $(shell ...) isn't a good idea in make, as it always runs regardless of the target. Worse yet, those shell commands are not a trivial amount of processing. Ideally, this information should be obtained *once* at the start of the build, cached in a file that depends on the necessary bits (e.g. parse the version from the changelog into a file that depends on debian/changelog), and then used from there. Whether that's done via make, or by having commands like dpkg-parsechangelog cache the relevant bits of thir output and check mtime on the files they parse. We should try to reduce the number of such things that are actually needed in debian/rules; if they're only needed in a particular target, or in some specific command, let's put them in that target or command. Also, things like "grep Version | cut ..." should really be replaced with things like "dpkg-parsechangelog -SVersion". It's unfortunate that that make can't run a command without using the shell. For that matter, all the override_* targets should ideally be handled in some way that doesn't involve a full invocation of make, if the target doesn't actually exist. That's harder, but it should be possible to run make once, parse the list of targets, and use those. If we can reduce the number of invocations of make, that would help as well. - Josh Triplett -- 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/20150723190551.GA2159@jtriplet-mobl1
Bug#793404: massive waste of CPU time in debian/rules by inline commands
* Eduard Bloch , 2015-07-23, 19:43: The problem: I see lots of $(shell ...) stuff. In boost, there are about 12 such calls. And they run dpkg-architecture or dpkg-parsechangelogs or similar commands. When this was done a just couple of times (i.e. before dh(7)), that's acceptable. But now, it looks like debian/rules is called many, many times through dh. One mistake boost makes is using ":=" instead of plain "=". Contrary to popular belief, the former almost always causes more evaluation of $(shell) stuff, specially when dh is involved. Anyway, in my packages, I fixed all problems with dh by not using dh. :-) -- Jakub Wilk -- 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/20150723190815.ga4...@jwilk.net
Bug#793404: massive waste of CPU time in debian/rules by inline commands
Quoting Jakub Wilk (2015-07-23 21:08:15) > * Eduard Bloch , 2015-07-23, 19:43: >>The problem: I see lots of $(shell ...) stuff. In boost, there are >>about 12 such calls. And they run dpkg-architecture or >>dpkg-parsechangelogs or similar commands. When this was done a just >>couple of times (i.e. before dh(7)), that's acceptable. But now, it >>looks like debian/rules is called many, many times through dh. > > One mistake boost makes is using ":=" instead of plain "=". Contrary > to popular belief, the former almost always causes more evaluation of > $(shell) stuff, specially when dh is involved. Could you elaborate on that? I never use short-form dh but would like to understand if the optimizations I've tried to do in CDBS might do more harm than good. - 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
Bug#793413: general: No samba config
Package: general Severity: important Dear Maintainer, * What led up to the situation? I need to easily share my windows ntfs drives to my family and there is no program for it like system-config-samba gui utility * What exactly did you do (or not do) that was effective (or ineffective)? I did use a code in terminal for instalation this utility and terminal hanged * What was the outcome of this action? Unable to locate package system-config-samba * What outcome did you expect instead? I want tu run and config my samba easily Also - there is a visual glitch (R9 280)- no screen VSYNC > screen tearing occurs sometimes in the browser, this i presume would be much worse after installing proprietary AMD driver (like in linux Mint) Also - mouse speed is too high - there is no deceleration option below the limit Also - my sound card (Xonar DX) plays too quiet - there is no alsa config utility to increse that hardware volume Also - pidgin sucks - does not download my contacts by itself (Gadu-Gadu) Also - there is nothing to enhance the sound like equalizer or dolby- headphones, just a raw sound is bad i need features -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- 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/20150723194605.15526.77929.reportbug@localhost
Re: Bug#793404: massive waste of CPU time in debian/rules by inline commands
Jonas Smedegaard wrote: > Quoting Jakub Wilk (2015-07-23 21:08:15) > > * Eduard Bloch , 2015-07-23, 19:43: > >>The problem: I see lots of $(shell ...) stuff. In boost, there are > >>about 12 such calls. And they run dpkg-architecture or > >>dpkg-parsechangelogs or similar commands. When this was done a just > >>couple of times (i.e. before dh(7)), that's acceptable. But now, it > >>looks like debian/rules is called many, many times through dh. > > > > One mistake boost makes is using ":=" instead of plain "=". Contrary > > to popular belief, the former almost always causes more evaluation of > > $(shell) stuff, specially when dh is involved. > > Could you elaborate on that? > > I never use short-form dh but would like to understand if the > optimizations I've tried to do in CDBS might do more harm than good. If you use :=, the shell command is immediately run and the result stored in the variable. So if you reference the variable a dozen times, the shell command gets run once. And if you reference the variable zero times, the shell command gets run once. If you use =, the shell command is run when the variable is evaluated. So if you reference the variable a dozen times, the shell command gets run a dozen times. And if you reference the variable zero times, the shell command gets run zero times. So := is an optimization if you expect to evaluate the variable more than once. It's a pessimization if you don't evaluate the variable. If the invocations of make for dh aren't referencing those variables, using := is a pessimization. - Josh Triplett -- 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/20150723205749.GA8552@jtriplet-mobl1
Bug#793404: massive waste of CPU time in debian/rules by inline commands
On Thu, Jul 23, 2015 at 09:08:15PM +0200, Jakub Wilk wrote: > * Eduard Bloch , 2015-07-23, 19:43: > >The problem: I see lots of $(shell ...) stuff. In boost, there are about > >12 such calls. And they run dpkg-architecture or dpkg-parsechangelogs or > >similar commands. When this was done a just couple of times (i.e. before > >dh(7)), that's acceptable. But now, it looks like debian/rules is called > >many, many times through dh. > > One mistake boost makes is using ":=" instead of plain "=". Contrary to > popular belief, the former almost always causes more evaluation of $(shell) > stuff, specially when dh is involved. Or you can use: lazy = $(eval $(1) = $$(if $$(___$(1)),,$$(eval ___$(1) := $(2)))$$(___$(1))) $(call lazy,VARIABLE_NAME,$$(shell command)) And then the command will only execute when you actually use VARIABLE_NAME for the first time. Mike -- 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/20150723221027.ga11...@glandium.org
Re: Facilitating external repositories
Wouter Verhelst writes ("Re: Facilitating external repositories"):
> On Thu, Jul 23, 2015 at 01:03:15PM +0100, Ian Jackson wrote:
> > The /name/ of the external repository should also be covered by the
> > signature.
>
> What would you describe as the "name" of the repository?
>
> The URL is already part of the sources.list file. Additionally, the
> deb822 form of the sources.list file is already configured to have a
> short and long Description: field.
Ah, I think the short and long Description are probably the answer. I
wasn't aware of that.
I was thinking that tools would want to show something to the user. A
Description is probably the right thing and if it is covered by the
signature then great.
> Am I missing something?
I think probably I was. (Also I may be missing something now, too - I
have just got back from the pub...)
Ian.
--
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/21937.28150.812508.153...@chiark.greenend.org.uk
Bug#793404: massive waste of CPU time in debian/rules by inline commands
Control: block -1 by 793330 Hi! On Thu, 2015-07-23 at 19:43:46 +0200, Eduard Bloch wrote: > Package: general > Severity: minor > The problem: I see lots of $(shell ...) stuff. In boost, there are about > 12 such calls. And they run dpkg-architecture or dpkg-parsechangelogs or > similar commands. When this was done a just couple of times (i.e. before > dh(7)), that's acceptable. But now, it looks like debian/rules is called > many, many times through dh. Making many, many calls of that inline > commands. Wasting many, many CPU cycles. All that just to retrieve the > same information all over again. There are multiple culprits that pile up here: 1) The /usr/share/dpkg/architecture.mk and /usr/share/dpkg/buildflags.mk lazy and caching value initialization is not effective. I had noticed it but had not yet checked if it was a problem with the makefiles or in make, etc. It appears is a bad interaction with the foreach, which defeats the lazy and cached evaluation. I guess I'll try to make the foreach work, or revert to an unrolled implementation. 2) debhelper's Dh_Lib.pm does not try to use existing dpkg-architecture variables from the environment. Those should not be expected to be present, but when using dpkg-buildpackage they will be present so it would be an optimization. I'll file a bug report about this. 3) Slow dpkg-parsechangelog implementation and usage: > In the emulated m68k environment, it spends about half an hour (guessed, > not measured) before starting the actual build, doing things like: > > | \_ /usr/bin/perl -w /usr/bin/dh build --with python2 --with python3 > | \_ /usr/bin/make -f debian/rules override_dh_auto_configure > | \_ /bin/sh -c dpkg-parsechangelog | grep Version | cut -d' ' > -f2 > | \_ /usr/bin/perl /usr/bin/dpkg-parsechangelog > | | \_ /usr/bin/perl /usr/lib/dpkg/parsechangelog/debian > -ldebian/changelog --file debia 3.1) As mentioned in the thread, callers can avoid the other shell commands and pipes by using -S. 3.2) debian/rules (or debhelper/cdbs) will still call the program for different changelog values. But dpkg-buildpackage has to parse the current and previous entries anyway, so we could preset values for those in the environment that could opportunistically be used by debian/rules and debhelper/cdbs. A possible drawback is that packages might accidentally rely on those variables w/o setting them beforehand. 3.3) dpkg-parsechangelog supports other changelog formats, and those are implemented by external parsers. This means it needs to scan the changelog twice, and then parse+output+parse the data from the parser. I've already implemented an optimization (to be included in dpkg 1.18.2) when forcing the format to be debian, that uses a builtin parser, which halves the execution time. «dpkg-parsechangelog -Fdebian». I guess I can take this further and use the builtin parser whenever the format is debian. And probably some others… Thanks, Guillem -- 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/20150723232012.ga32...@gaara.hadrons.org
Processed: Re: Bug#793404: massive waste of CPU time in debian/rules by inline commands
Processing control commands: > block -1 by 793330 Bug #793404 [general] massive waste of CPU time in debian/rules by inline commands 793404 was not blocked by any bugs. 793404 was not blocking any bugs. Added blocking bug(s) of 793404: 793330 -- 793404: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793404 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b793404.143769362926628.transcr...@bugs.debian.org
Bug#793432: ITP: python-wordpress-xmlrpc -- Python library for WordPress XML-RPC integration
Package: wnpp
Severity: wishlist
Owner: Daniel Stender
* Package name: python-wordpress-xmlrpc
Version : 2.3
Upstream Author : Max Cutler
* URL : https://github.com/maxcutler/python-wordpress-xmlrpc
* License : Expat
Programming Lang: Python
Description : Python library for WordPress XML-RPC integration
Library for connecting to Wordpress blogs over their XML-RPC interface [1],
creating and retrieving posts etc. Further developed than python-wordpress-
library. I'm going to maintain this in DPMT. The generated binaries are going
to be python{,3}-wordpress-xmlrpc.
[1] http://python-wordpress-xmlrpc.rtfd.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/20150724002908.10275.89131.reportbug@localhost
Work-needing packages report for Jul 24, 2015
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: 678 (new: 1) Total number of packages offered up for adoption: 179 (new: 5) Total number of packages requested help for: 50 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: courierpassd (#793143), orphaned 2 days ago Installations reported by Popcon: 38 677 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: acorn (#792862), offered 4 days ago Installations reported by Popcon: 2 node-globule (#792863), offered 4 days ago Installations reported by Popcon: 1 node-minimist (#792864), offered 4 days ago Description: Argument options parsing for Node.js Reverse Depends: node-optimist Installations reported by Popcon: 158 node-q (#792865), offered 4 days ago Installations reported by Popcon: 1 node-tmp (#792866), offered 4 days ago Installations reported by Popcon: 1 174 older packages have been omitted from this listing, 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 1998 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache goplay muon muon-discover packagesearch Installations reported by Popcon: 44645 athcool (#278442), requested 3922 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 27 awstats (#755797), requested 365 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4047 balsa (#642906), requested 1397 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 730 cardstories (#624100), requested 1550 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 6 cups (#532097), requested 2238 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (68 more omitted) Installations reported by Popcon: 124741 debtags (#567954), requested 1998 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 1882 developers-reference (#759995), requested 327 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 12615 ejabberd (#767874), requested 262 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib Installations reported by Popcon: 754 fbcat (#565156), requested 2017 days ago Description: framebuffer grabber Installations reported by Popcon: 155 freeipmi (#628062), requested 1519 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev libfreeipmi16 libipmiconsole-dev libipmiconsole2 (6 more omitted) Installations reported by Popcon: 6028 gnat-gps (#496905), requested 2520 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 443 gnokii (#677750), requested 1132 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: 1202 gridengine (#703256), requested 858 days ago Description: Distributed resource management Reverse Depends: gridengine-client gridengine-drmaa-dev gridengine-exec gridengine-master gridengine-qmon logol Installations reported by Popcon: 1101 grub2 (#248397), requested 4091 days ago Description: GRand Unified Bootloader Reverse Depends: grml-rescueboot grml2usb grub-coreboot grub-coreboot-bin grub-coreboot-dbg grub-disk grub-efi grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-dbg (37 more omitted) Installations reported by Popcon: 145098 guake (#
Bug#793439: ITP: virtualbox-ext-pack -- support for USB 2.0 devices, VirtualBox RDP and PXE boot for Intel cards
Package: wnpp Severity: wishlist Owner: Unit 193 * Package name: virtualbox-ext-pack Version : 5.0.0 Upstream Author : Oracle Corporation * URL : https://www.virtualbox.org/ * License : VirtualBox PUEL Description : support for USB 2.0 devices, VirtualBox RDP and PXE boot for Intel cards VirtualBox requires an extension pack in order to provide support for RDP, as well as USB 2.0 and PXE booting for Intel network cards, etc. This PUEL licensed extension pack is free for personal use. This package enhances VirtualBox as packaged in Debian. This is a downloader package, doesn't contain the actual extension pack in order to comply with the license. The current packaging is sitting in http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox-ext-pack.git -- 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/20150724030917.6794.49557.reportbug@Loki.local
Processed: debhelper: Could use dpkg-architecture env vars if present
Processing control commands: > block 793404 by -1 Bug #793404 [general] massive waste of CPU time in debian/rules by inline commands 793404 was blocked by: 793330 793404 was not blocking any bugs. Added blocking bug(s) of 793404: 793440 -- 793404: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793404 793440: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793440 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b.143770941824604.transcr...@bugs.debian.org
Processed: debhelper: Could use Dpkg::Arch::debarch_is instead of dpkg-architecture
Processing control commands: > block 793404 by -1 Bug #793404 [general] massive waste of CPU time in debian/rules by inline commands 793404 was blocked by: 793330 793440 793404 was not blocking any bugs. Added blocking bug(s) of 793404: 793443 -- 793404: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793404 793443: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793443 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b.14377127558127.transcr...@bugs.debian.org
Bug#793446: ITP: fwupd -- Firmware update daemon
Package: wnpp Severity: wishlist Owner: Mario Limonciello * Package name: fwupd Version : 0.1.4 Upstream Author : Richard Hughes * URL : https://github.com/hughsie/fwupd * License : GPL Programming Lang: C Description : Firmware update daemon fwupd is a daemon to allow session software to update device firmware. You can either use a GUI software manager like GNOME Software to view and apply updates, the command-line tool or the system D-Bus interface directly. Currently, firmware updates using the UEFI capsule format and for the ColorHug are supported. More formats may be supported in the future. Currently Daniel Jared Dominguez and I have been collaborating on packaging for fwupd located at http://linux.dell.com/cgi-bin/cgit.cgi/debian/fwupd.git/ We are discussing assembling a packaging maintenance team for firmware related packages such as fwupd, fwupdate, efivar, etc. Upstream has not yet released the 0.1.4 release. That is the first release that should be put into Debian. The 0.1.3 release doesn't yet properly support UEFI capsules. -- 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/20150724055002.3479.1913.reportbug@supermario-XPS-13-9343
Trouble making an ITP
Hi, I'd like to package (and maintain) a small and old game called Down!, written in Ruby/SDL [1]. I sent an ITP using reportbug -B debian wnpp (since I'm using Mint 17.2), filled it out. I was to receive a confirmation but got no such message. What could go wrong? Thanks Marcin
