Bug#1010175: ITP: ruby-prawn-templates -- Prawn::Templates allows using PDFs as templates in Prawn
Package: wnpp Severity: wishlist Owner: Keith Packard X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Ruby Extras Maintainers * Package name: ruby-prawn-templates Version : 0.1.2 Upstream Author : Gregory Brown * URL : https://github.com/prawnpdf/prawn-templates * License : Ruby or GPL-2 or GPL-3 Programming Lang: Ruby Description : Prawn::Templates allows using PDFs as templates in Prawn A extension to prawn that allows one to include other pdfs either as background to write upon or to combine several pdf documents into one. This package is required to implement pdf import in ruby-asciidoctor-pdf which was left out because of a bug in pdf-core. There is a patch for the pdf-core bug which is upstream and will be released eventually; it would be good to have this package ready in debian for when the pdf-core bug is fixed so that a new version of ruby-asciidoctor-pdf can be released that enables this feature.
Re: length of Debian copyright files
Simon McVittie writes: > One thing that the ftp team clarified somewhat recently is that in > most cases, we must track all the copyright notices that exist in the > upstream source, and copy them into d/copyright. As an example, I've got a package in the new queue with a 5077 line copyright file, with 75 'unique' licenses (BSD licensed software picks up a lot of variation over thirty years). -- -keith signature.asc Description: PGP signature
Re: Bug#881333: Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64
Steve Langasek writes: > Long ago I heard rumors of development work on mesa that would allow it to > function as a proxy library, so that apps would link against libGL as needed > and the GL implementation would use a hardware-accelerated GLES driver where > possible, falling back to software GL where necessary. This seems unlikely -- I believe GLES and GL have different semantics in a few places which makes implementing GL on GLES inefficient; mostly that GLES is missing stuff that GL applications often use, but I think there are places where GLES is just different, including in how GLSL works. I haven't tried, but I would expect that applications could use both GL and GLES APIs at the same time, even to the same window. If this does work with Mesa, then linking Qt against GLES wouldn't restrict applications using free drivers at least? -- -keith signature.asc Description: PGP signature
Re: MemberBenefits - Steam Keys (Was: Bits from the DPL (May 2018))
Alexandre Viau writes: > On 2018-05-31 12:33 PM, Chris Lamb wrote: >> [11] https://wiki.debian.org/MemberBenefits > Oh, this reminds me of something. > > Has anyone gotten replies to their requests sent to > debian-st...@collabora.com for the Steam subscriptions mentioned in the > MemberBenefits page? > > I think that I have sent two mails in the past 3 years but have gotten > no responses. > > Should we remove this benefit from the wiki page? Or do we have someone > to contact about it? I'll look into this; I'm doing some work for them of late. -- -keith signature.asc Description: PGP signature
Bug#894271: ITP: cmark-gfm -- GitHub enhanced version of cmark, the common markdown parser
Package: wnpp Severity: wishlist Owner: Keith Packard * Package name: cmark-gfm Version : 0.28.3.gfm.12 Upstream Author : John MacFarlane * URL : https://ithub.com/github/cmark * License : BSD, MIT/X Programming Lang: C Description : GitHub enhanced version of cmark, the common markdown parser Common Markdown provides a useful standardized language for building formatted documents. The 'cmark' parser, already in Debian, provides a basic parser implementing the core Common Markdown standard. People involved in the GitHub system have forked 'cmark' in a way which leaves the core language unchanged but extends the system to add table and other additional formatting methods. This extended version of Common Markdown is used within the github system for formatting .md files in project repositories and, as such, is becoming widely used within that environment. I've got preliminary packaging working here: https://anonscm.debian.org/cgit/users/keithp/cmark-gfm.git/ I'm packaging this so I can use it to replace asciidoc in the altos package as asciidoc is being deprecated.
Re: suil - current packaging query
Phil Wyett writes: > Any thoughts and how suil should be better packaged welcome. Any reason you couldn't create a binary package (suil-binaries) and then two virtual packages (suil-qt and suil-gtk) which had the appropriate dependencies on the necessary toolkit? Presumably suil would need to be configured as appropriate to load the right underlying toolkit, that could be done with alternatives? Another virtual package (suil) could then depend on suil-qt or suil-gtk as desired to select a suitable default, probably gtk (given our current default desktop). Users could then install suil-qt instead to get a version suitable for use in a qt-dominant environment. -- -keith signature.asc Description: PGP signature
About the TC vote on libpam-systemd
I'd like to apologize to the systemd maintainer team, and to Tollef in particular for my TC vote on the libpam-systemd bug. The discussion on this issue was an excellent model of the Debian community at work: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578 Josh Triplett (who is a systemd proponent although not a member of the Debian systemd team) raised some salient technical concerns about the effect of the proposed change, and Christian Seiler did a bunch of research to answer them. The end result of this collaboration was that all agreed that the proposed solution was a good choice for Debian, with Josh writing: > I don't see any obvious further steps that need to occur other than > flipping the dependency around. (It might be a good idea for the > libpam-systemd dependency to bump its versioned dependency on > systemd-shim to (>= 8-4), but that's up to the libpam-systemd > maintainers.) What should have happened at this point was to re-engage with the Debian systemd team and get them to also review the discussion. We really did learn new things about what the effect of this change would be. One way would have been to simply offer the systemd maintainers advice under ยง6.1.5, knowing that they would act in good faith on it. -- keith.pack...@intel.com pgpFncuKBhu8x.pgp Description: PGP signature
Re: Technical committee appointment
Lucas Nussbaum writes: > Keith, welcome to our Technical Committee! Thanks, Lucas, and all of the rest of the Debian Tech Committee for your support. I look forward to serving the Debian project in this additional role to the best of my ability. -- keith.pack...@intel.com pgpWC0RklOgW2.pgp Description: PGP signature
Re: Multi-Arch .udeb ?
On Tue, 28 Jun 2011 08:14:07 +0100, Steve Langasek wrote: > Yep, looks almost identical to my patch here, with only one difference: the > runtime support packages need to be marked Multi-Arch: foreign in order to > satisfy the dependencies of the multiarch libraries. Attached. (This is > also bug #614208.) Then I guess I should mark that as closed then. I've pushed updated packaging bits; I wouldn't mind if you'd check and make sure they look right before I upload the resulting package. -- keith.pack...@intel.com pgplAxFDL1YQG.pgp Description: PGP signature
Re: Multi-Arch .udeb ?
On Tue, 28 Jun 2011 00:04:23 +0100, Steve Langasek wrote: > The convention I've adopted so far for udeb-building packages has been to > install libraries in /usr/lib instead of to /usr/lib/$arch. Ok, that makes sense to me. Of course, it's also harder for me to manage in the package as I'm installing the same library in the .udeb as I do in the library .deb file. I'll manage. > BTW, if the package you're asking after happens to be fontconfig, I have a > patch here that I'll be sending on shortly. :-) Oddly, it is (the only package I have with a .udeb). I'm running a multi-arch version of that on this machine and it appears to work correctly. You can see this at: git://git.debian.org/git/pkg-freedesktop/fontconfig-debian -- keith.pack...@intel.com pgpXtEWsTI3sy.pgp Description: PGP signature
Multi-Arch .udeb ?
On Mon, 27 Jun 2011 11:54:53 +0100, Steve Langasek wrote: Non-text part: multipart/signed > It is with excitement and trepidation that I write to you today about the > status of multiarch support in Debian. Thanks for the update. I'm afraid I haven't been paying close attention, but a cursory search didn't uncover any description of what I'm supposed to do with a .udeb that includes a shared library in our glorious Multi-Arch world of the future. I'm assuming that any files destined for /usr/lib should land in the architecture-specific sub-directory, right? -- keith.pack...@intel.com pgpOMljwYtiXe.pgp Description: PGP signature
Re: GPG Key Signing
On Wed, 2005-07-20 at 23:27 +0200, David Weinehall wrote: > The only *listed* offers for Oregon are: > > OR, Bend: Nick Rusnov <[EMAIL PROTECTED]> > OR, Medford: Sam Powers <[EMAIL PROTECTED]> > > but I'm not familiar enough with US geography to know if that's close > enough. Those are quite a ways from Portland. I'm in Portland, but haven't put myself on the list for no particularily good reason. -keith signature.asc Description: This is a digitally signed message part
Re: is xprint still used by mozilla, etc?
Around 12 o'clock on Mar 11, Drew Parsons wrote: > Keith said Xprint is increasingly irrelevant, but I'm not aware how this > language issue can be satisfactorily solved without Xprint. Mozilla is currently integrating Pango support for complex text layout issues; using that for printing would be a logical step as it would support many more scripts than Mozilla does today, even with Xprint. But, as of today, Mozilla does rely on Xprint for non-Latin printing, and so it does indeed remain a relevant part of Debian. I am working hard to make sure the Debian desktop supports all of the world's languages in an efficient and correct fashion. I'm hoping to provide a better solution than what is provided by Xprint today, but I also acknowledge that Xprint is still useful in some environments and hence has a place on some desktops for now. It should be available, but it shouldn't be mandatory -- many of us print quite happily from dozens of applications in many languages without the benefit of Xprint on our machine; Mozilla remains an exceptional case in this regard, one which I hope changes in the future. -keith pgpYpWOrFfM65.pgp Description: PGP signature
Re: is xprint still used by mozilla, etc?
Around 14 o'clock on Mar 10, Joey Hess wrote: > Back history: I added xprt-xprintorg to the desktop task at the end of > January after receiving bug #226605 which stated that > > More and more applications like Firebird, Thunderbird, Mozilla, Java, > Openoffice and more need it so the > default Debian desktop and print server installations should provide it. I'm afraid Xprint is a political football; some people will say that more and more projects depends on it, and others (myself included) will say that it is decreasingly relevant. As far as I understand it, neither Mozilla nor OpenOffice are built to require Xprint in the Debian packages. Mozilla can be configured to use Xprint, and I believe it has additional capabilities not present in the bare postscript output mechanism. I believe the depends and recommends mechanism is sufficient to ensure that Xprint is available where necessary, and that we shouldn't burden the desktop task with optional software which provides no direct user-visible functionality. -keith pgpfodJlu1923.pgp Description: PGP signature
