Bug#812174: ITP: letsencrypt-sh -- ACME client implemented in Bash
Hi Mattia, On Tue, 2016-04-05 at 21:15 +, Mattia Rizzolo wrote: > On Tue, Mar 29, 2016 at 05:45:44PM +0200, Daniel Beyer wrote: > > Hi Mattia, > > > > Am Montag, den 28.03.2016, 21:44 + schrieb Mattia Rizzolo: > > > Hi Daniel :) > > > > > > On Sun, Mar 27, 2016 at 01:01:18PM +0200, Daniel Beyer wrote: > > > (...) > > > > > > > The infrastructure I needed letsencrypt.sh for enables the proxy module > > in a virtualhost, rather doing it the debian-"mods-enabled"-way. That's > > why it was a virtualhost (it had to be loaded at the very end to work). > > But this is a rather uncommon setup and providing a config snippet is > > definitely the way to go here. Thanks for changing it and switching to > > dh_apache2. > > Umh, now, I haven't checked as atm I don't have anything handy to check > this, and I'm not and apache2 master, but it really ought to work > anyway; unless you explicitly allow it again it should really work. > I had the impression the order matters (at least with Apache 2.2), but actually this special case is no longer around for me. Anyhow, using conf.d is the better approach. > On the bright side, I've made changes to my little deployment and now > I'm using the -apache2 package too. Great. > I've made some changes to it, I think the most "difficult" change is > commit 365c3380ccab44b611d7a3edd6a9c4d6cf8ccabe please tell me what you > think of that. I wrote my reasons in the commit msg, but tell me :) > It looks reasonable to demote it to Recommends. The original (ProxyPass|Alias)Match in debian/letsencrypt.sh.conf might have been a bit paranoid. My intention was to make sure one really can load only the challenge responses. But I think dropping the *Match should not be a security issue at all. The rest of your changes are fine, thanks. > > > I've already installed the resulting .deb on one of my servers, but I > > > have to admit that I already have some infrastructure around LE, so I > > > won't use the packaged configuration, nor the apache snippet by myself > > > (at least not yet). > > > > > > > I have quite some infrastructure that I would like to use it for. I > > check if I can migrate one candidate to fully make use of the packaging > > later this week. > > How did it went? It works for me. > > > > (...) > > > > Yeah, you're right - pretty unhandy. I renamed it to simply > > letsencrypt.sh-apache2 in debian/master - but feel free to propose an > > other name. > > that name's cool for me! :) > Great. > > I would like to see the following features added to the packaging: > > - Ship some automatism, so the renews do not need to be done manually > > I don't know. I've yet to enable automatic renewals. Given that I'm > still doing stuff and playing with it I run so often anyway. > > Also, automatic renewals implies cron: that means deciding how often you > want to do that. And considering that letsencrypt.sh does not have a > silent mode really useful for cron (I wouldn't want to be "constantly" > emailed just to know that nothing has been done). > > And also means we need to install a letsencrypt.sh user or something to > run it with, and then IMHO it'll become a really complicated package for > a shell scrip... > Yes, it increases the complexity of the package. Let's not do this in the initial version, but keep it in mind for sometime in future. > > - Add ngnix support (similar to the apache2 one) > > I'm not a ngnix person, I wouldn't know how to do it. > What about leaving it for somebody else to supply a patch? > Agreed. > > Besides that, it would be wise to deny execution by user root per > > default, but this should better be implemented upstream. I'll try to > > work on this later this week - or more likely on the weekend. > > Yes, this should be done upstream. > > What do think is it needed after all of this? > I'm not sure we really need an '--allow-root'-switch. I think I draft an PR on upstream's GitHub repository and let them decide on this. I'll try to get this done as soon as possible. I think the version we now have is good for an initial release. If you agree, feel free to upload it to unstable. Greetings Daniel signature.asc Description: This is a digitally signed message part
Bug#812174: ITP: letsencrypt-sh -- ACME client implemented in Bash
Hi Mattia, Am Montag, den 28.03.2016, 21:44 + schrieb Mattia Rizzolo: > Hi Daniel :) > > On Sun, Mar 27, 2016 at 01:01:18PM +0200, Daniel Beyer wrote: > (...) > > I think your apache snippet is cool, actually. > I improved it a bit the thing, by moving it to be a config snippet, > instead of being treated as a virtualhost, and by using dh_apache2 > instead of manually try (and fail, e.g. you forgot to remove the thing > when removing the package) to get it right :) > The infrastructure I needed letsencrypt.sh for enables the proxy module in a virtualhost, rather doing it the debian-"mods-enabled"-way. That's why it was a virtualhost (it had to be loaded at the very end to work). But this is a rather uncommon setup and providing a config snippet is definitely the way to go here. Thanks for changing it and switching to dh_apache2. >> (...) > > Let me know if you think we can base our work on what I've done so far, > > or if we instead should make a fresh start. > > See this: > https://anonscm.debian.org/git/letsencrypt/letsencrypt.sh.git/ > I updatd it to the released version. I kind of changed a bit the git > repository layout (using debian/master instead of debian/experimental, > and using master (following the upstream one) instead of > upstream/experimental. README.source is not really the thing I followed > to import the new source, but as I did a lot of stuff while updating the > thing I think we'll need the next release to see what we actually need > to do to import a new upstream (also, I'm not really a gbp master, I > committed the pristine-tar info manually with `pristine-tar commit...`) > Great this is will be maintained within Debian's letsencrypt-devel. I just closed the old packaging repository on GitHub in favor of the new one at anonscm.d.o. I'm fine with the changed repository layout, meaning the primary packaging work will be done in debian/master. I updated d/gbp.conf accordingly, as well as README.source. As already mentioned in private to you, I implemented 'When upstream uses Git/No upstream tarballs' [1] here. >From my understanding we do not need to track upstream changes in a branch at all, since gbp defaults to '--git-upstream-tree=TAG'. Thus we most likely can drop the branch 'upstream/master' from the Debian packaging repo - hence I'm not 100% sure about that. [1] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL > I did a buch of other changes, that you may agree or not, please have a > look and comment on them; I'm quite open, if you don't like some commits > I can happily accept to see them reverted (some/most of them, some other > I definitely want to see them keep) > I'm fine with them ;) > You should have commit access on it, so feel free to just push stuff and > at most we can discuss it later. > I've pushed some commits to debian/master, you might want to have a look at them. > I've already installed the resulting .deb on one of my servers, but I > have to admit that I already have some infrastructure around LE, so I > won't use the packaged configuration, nor the apache snippet by myself > (at least not yet). > I have quite some infrastructure that I would like to use it for. I check if I can migrate one candidate to fully make use of the packaging later this week. > Something I need help/suggestion for: I quite dislike the name > letsencrypt.sh-challenge-response-apache2, I find it way too long :\ > Can we think of something more nice? :) > Yeah, you're right - pretty unhandy. I renamed it to simply letsencrypt.sh-apache2 in debian/master - but feel free to propose an other name. I would like to see the following features added to the packaging: - Ship some automatism, so the renews do not need to be done manually - Add ngnix support (similar to the apache2 one) Besides that, it would be wise to deny execution by user root per default, but this should better be implemented upstream. I'll try to work on this later this week - or more likely on the weekend. Greetings Daniel
Bug#812174: Update #812174: Updated wnpp info
Package: wnpp Severity: wishlist Owner: Daniel Beyer <d...@deb.ymc.ch> * Package name: letsencrypt.sh Version : 0.1.0 Upstream Author : Lukas Schauer <lukas.scha...@googlemail.com> * URL : https://github.com/lukas2511/letsencrypt.sh * License : Expat Programming Lang: Bash Description : ACME client implemented in Bash The letsencrypt.sh ACME client allows signing certificates with an ACME server, like the one provided by the Let’s Encrypt certificate authority (letsencrypt.org). It is implemented as a relatively simple Bash script, which uses curl to communicate with the ACME server and OpenSSL to deal with keys, sign requests and certificates. . The ACME (Automated Certificate Management Environment) protocol makes it possible to automatically obtain browser-trusted certificate. signature.asc Description: This is a digitally signed message part
Bug#812174: ITP: letsencrypt-sh -- ACME client implemented in Bash
Hi Mattia, thanks a lot for pushing this ITP. On Sat, 2016-03-26 at 21:07 +, Mattia Rizzolo wrote: > On Thu, Jan 21, 2016 at 08:10:13AM +0100, Daniel Beyer wrote: > > * Package name: letsencrypt-sh > > Is there a good reason not to call this package 'letsencrypt.sh', with a > dot, as the official name? > No, there is no good reason for it. I wrongly thought a dot in a package name is not permitted. Let's name it letsencrypt.sh. > > Anyway, this email was to ask how it's going with this. Since I needed it, I made some initial packaging [1] on GitHub, which fit my needs right know. It of course need some more work to get it ready for Debian (e.g. it needs to be rebased against upstream's v0.1.0 and the repo should be moved to anonscm.d.o). > It should be a > fairly simple package, and I'm quite interested in it (can also sponsor > it or help to comaintain it, as you like, if you need it!). > I might have overcomplicated things a bit with the current packaging approach (e.g. providing apache configuration). You might want to take a look yourself and share your thoughts. If you're up for it, I gratefully would like to accept your offer to co-maintain this package. Additionally it might be worth to ask having it under the umbrella of Debian Let's Encrypt [2]. Let me know if you think we can base our work on what I've done so far, or if we instead should make a fresh start. Greetings Daniel [1] https://github.com/ymc/letsencrypt.sh [2] https://qa.debian.org/developer.php?login=letsencrypt-devel%40lists.alioth.debian.org signature.asc Description: This is a digitally signed message part
Bug#812174: ITP: letsencrypt-sh -- ACME client implemented in Bash
Package: wnpp Severity: wishlist Owner: Daniel Beyer <d...@deb.ymc.ch> * Package name: letsencrypt-sh Version : 0.0.0~2016.01.21~git23b0ef5 Upstream Author : Lukas Schauer <lukas.scha...@googlemail.com> * URL : https://github.com/lukas2511/letsencrypt.sh * License : Expat Programming Lang: Bash Description : ACME client implemented in Bash The letsencrypt.sh ACME client allows signing certificates with an ACME server, like the one provided by the Let’s Encrypt certificate authority (letsencrypt.org). It is implemented as a relatively simple Bash script, which uses curl to communicate with the ACME server and OpenSSL to deal with keys, sign requests and certificates. . The ACME (Automated Certificate Management Environment) protocol makes it possible to automatically obtain browser-trusted certificate. signature.asc Description: This is a digitally signed message part
Bug#748834: Quite some more Symfony2 Components needed in Debian for SIlex
For the record: All needed Symfony components are now found in Debian and I just found out that the 2.3 series is recent enough for Silex (originally I wrongly looked at Silex's master branch were at least Symonfy 2.4 is required). Thus I'm currently working on an initial packaging of Silex. signature.asc Description: This is a digitally signed message part
Bug#513646: Packaging repository changed
For the record: The existing Debian packaging repository has been dropped and a new one replaces it. The new one can be found at: http://anonscm.debian.org/gitweb/?p=pkg-php/symfony.git;a=summary Further details can be found at: http://lists.alioth.debian.org/pipermail/pkg-php-pear/2014-June/002855.html signature.asc Description: This is a digitally signed message part
Bug#513646: [pkg-php-pear] Let's reconsider the way Symfony2 Components are packaged for Debian
On Sat, 2014-05-24 at 15:33 +0200, Daniel Beyer wrote: On Fri, 2014-05-23 at 17:12 -0400, David Prévot wrote: Hi Daniel, (..) You may wish to transform #513646 as your ITP too. Just done that. I'll put a repo on git.d.o/git/pkg-php as soon as I have something worth putting there. I've pushed some initial packaging, which can be found at: http://anonscm.debian.org/gitweb/?p=pkg-php/php-symfony.git;a=summary David, you might want to take a look onto this and check if I'm on the right track. I decided that manually adding all those dependencies to d/control is much too error-prone and found a hackish way to use dh_phpcomposer for that: I simply temporarily symlink the /debian folder on each component's source-dir and run dh_phpcomposer from there). Having a way to tell dh_phpcomposer where to look for composer.json would be great, but I did not found the to check how this could be implemented, yet. I'll add the rest of the 28 components soon and do a license check. I'm not sure which version of Symfony to package. According to upstream's roadmap [1]: - 2.3 series is an LTS and gets security fixes till 05/2017 - 2.4 series gets those till 01/2015 - upcoming 2.5 till 07/2015 - 2.6 most likely will not be released in time for the Jessie freeze In order to benefit the most from upstream's maintenance work, I tend to go back to 2.3 (for Jessie). What's your opinion on that? BTW: I checked the currently packaged components in Debian. Only php-symfony2-yaml has a version newer than 2.3. [1] http://symfony.com/roadmap Greetings Daniel signature.asc Description: This is a digitally signed message part
Bug#513646: Update wnpp info
Package: wnpp Severity: wishlist Owner: Daniel Beyer d...@deb.ymc.ch * Package name: php-symfony-components Version : 2.4.5 Upstream Author : Fabien Potencier fab...@symfony.com * URL : http://symfony.com/ * License : MIT Programming Lang: php Description : Reusable set of php components The Symfony Components is a reusable set of standalone, decoupled and cohesive components. They are written in php with the goal to solve common web development problems. They form the base of the Symfony full-stack web framework. Currently only a few components of the currently 28 available ones are packaged for Debian. This is a new approach to have all the components in Debian and maintain them as a whole (under the umbrella of PHP PEAR Maintainers). Preliminary discussion started on pkg-php-pear list: http://lists.alioth.debian.org/pipermail/pkg-php-pear/2014-May/002760.html signature.asc Description: This is a digitally signed message part
Bug#748834: Quite some more Symfony2 Components needed in Debian for SIlex
Digging through the dependencies of Silex, I made a list of Symfony2 Components missing in Debian. Already packaged are four. Those are: [1] event-dispatcher [2] routing [3] finder [4] process (finder and process are needed for tests, only) Two are missing as runtime dependencies: http-foundation http-kernel An other 14 are required to run tests: browser-kit config css-selector debug dom-crawler form locale monolog-bridge options-resolver security serializer translation twig-bridge validator This is just a list of the Symfony2 Components missing. There of course are more besides them. I intend to delay my work on Silex till a way is figured out how to get (and maintain) such a number of new Symfony2 packages into (and in) Debian. The discussion about that currently can found at: http://lists.alioth.debian.org/pipermail/pkg-php-pear/2014-May/002760.html Daniel [1] https://packages.debian.org/php-symfony-eventdispatcher [2] https://packages.debian.org/php-symfony-routing [3] https://packages.debian.org/php-symfony-finder [4] https://packages.debian.org/php-symfony-process signature.asc Description: This is a digitally signed message part
Bug#748834: ITP: silex -- php micro framework
Package: wnpp Severity: wishlist Owner: Daniel Beyer d...@deb.ymc.ch * Package name: silex Version : 1.2.0 Upstream Author : Fabien Potencier fab...@symfony.com * URL : http://silex.sensiolabs.org/ * License : MIT Programming Lang: php Description : php micro framework Silex is a concise, extensible and testable micro framework for php. It is based on the Symfony2 Components and Pimple and inspired by Sinatra. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140521064936.30457.19249.report...@zmaj.evo
Bug#748834: ITP: silex -- php micro framework
Hi David On Wed, 2014-05-21 at 06:52 -0400, David Prévot wrote: Hi Daniel Le 21/05/2014 02:49, Daniel Beyer a écrit : Package: wnpp Silex is a concise, extensible and testable micro framework for php. It is based on the Symfony2 Components and Pimple and inspired by Sinatra. Please consider maintaining it inside the PHP PEAR Maintainers team (there are many Composer packages in the team too), with its reverse dependencies (some Symfony 2 Components are already there). I’m willing to take care of Pimple if that’s OK with you (we already ship an embedded copy in owncloud, and I’d be happy to get rid of it, your ITP motivates me to finally do that). I definitely intend to put Silex under the umbrella of the PHP PEAR Maintainers team. I guess I should have mentioned that in the ITP (and CC pkg-php-pear). I saw you just opened an ITP for Pimple. Thanks a lot for that. I did not check which other dependencies are missing for Silex in Debian. But I think there is an ongoing effort to package Symfony2 components for Debian and I would be willing to join. Greetings Daniel signature.asc Description: This is a digitally signed message part
Bug#748834: ITP: silex -- php micro framework
On Wed, 2014-05-21 at 13:07 -0400, David Prévot wrote: Hi Daniel, Le 21/05/2014 02:49, Daniel Beyer a écrit : I definitely intend to put Silex under the umbrella of the PHP PEAR Maintainers team. Great! Do you have any particular reason for wanting Silex in Debian, is it a dependency for something else? (That’s just me being curious, you’re free to ignore that question.) I make use of Silex for various micro applications. Those are packaged as .deb packages and each of those packages embed its own Silex (and Twig an Pimple and so on). Instead of trying to maintain this growing embed hell any longer, I decided to get rid of it and instead do something more reasonable by maintaining Silex inside Debian. I saw you just opened an ITP for Pimple. Thanks a lot for that. You’re welcome. Given how small it is, and that I already use it, the upload will happen really soon™ anyway (with its test suite enable for ci.d.n too). Great. And thanks for mentioning ci.d.n, which I wasn't aware of before. I did not check which other dependencies are missing for Silex in Debian. But I think there is an ongoing effort to package Symfony2 components for Debian and I would be willing to join. Nice, some Symfony 2 Components may need to be packaged, but since some already are, their packaging should be really straightforward (I’d advise to take case of one of those as a start, ask for review within the team, and once everything is fine, continue with the others). I'll do that. signature.asc Description: This is a digitally signed message part
Bug#645883: [pkg-php-pear] Bug#645883: Current status of twig
On Mon, 2014-05-12 at 11:15 +0200, Roland Mas wrote: Daniel Beyer, 2014-05-12 07:54:43 +0200 : [...] I pushed everything I've done last week to anonscm.d.o [1] and uploaded the package again to mentors [2]. Roland, can you have an other look onto the package, especially the new parts [3] regarding the newly added php-twig-doc package? I just did. The package looks fine, and I uploaded it. Thanks! Since I plan on using it for FusionForge, you may hear from me as a user in the not-too-distant future if I find bugs :-) That's just great. Really thanks a lot for the upload. signature.asc Description: This is a digitally signed message part
Bug#645883: [pkg-php-pear] Bug#645883: Current status of twig
On Mon, 2014-05-05 at 13:31 +0200, Daniel Beyer wrote:
On Mon, 2014-05-05 at 12:12 +0200, Roland Mas wrote:
The main nit I have is that the testsuite doesn't pass. When I run
pdebuild, the override_dh_auto_test target in debian/rules runs phpunit,
and phpunit fails one test with the following error:
,
| There was 1 failure:
|
| 1) Twig_Tests_IntegrationTest::testIntegration with data set #23
('expressions/ends_with.test', 'Twig supports the ends with operator',
'', array('
| {{ \'foo\' ends with \'o\' ? \'OK\' : \'KO\' }}
| {{ not (\'foo\' ends with \'f\') ? \'OK\' : \'KO\' }}
| {{ not (\'foo\' ends with \'foowaytoolong\') ? \'OK\' : \'KO\' }}'),
false, array(array('--DATA--
| return array()
| --EXPECT--
| OK
| OK
| OK', '
| return array()
| ', '', '
| OK
| OK
| OK')))
| Twig supports the ends with operator (in expressions/ends_with.test)
| Failed asserting that two strings are equal.
| --- Expected
| +++ Actual
| @@ @@
| 'OK
| -OK
| -OK'
| +KO
| +KO'
|
| /tmp/buildd/twig-1.15.1+dfsg/lib/Twig/Test/IntegrationTestCase.php:140
| /tmp/buildd/twig-1.15.1+dfsg/lib/Twig/Test/IntegrationTestCase.php:28
`
I'm not sure exactly what that means, but since the source package
generates an arch-specific binary package it's quite possible that the
autobuilders will fail on that. And regardless of the biuldds, it's
better if the testsuite passes.
Funny, the tests do not fail under wheezy(-backports), but they do fail
under jessie and sid (both with the error above). I'll try to take a
look at this in the evening.
It looks like this is related to php 5.5.11. With php 5.5.12 which now
can be found in jessie and sid the problem is gone. I'll try to check
what's wrong with Twig and php 5.5.11. But for now this no longer should
block this package, since tests passes with the versions of php
currently found in wheezy, jessie and sid.
Also, I found out that https://github.com/fabpot/Twig/issues/1118 is
now closed. It might make sense so update the packaging accordingly
(maybe add a new php-twig-doc binary package?).
Thanks for your efforts, this package is almost in shape!
Great, I guess I should go and thank some people like my colleague at
work for finally getting this resolved. I already have a variant laying
around that builds a -doc from the source, so this should not delay the
packing much.
The doc no longer gets removed from upstream's tarball, the '+dfsg' is
removed from the Debian version and a new binary package 'php-twig-doc'
is build.
I pushed everything I've done last week to anonscm.d.o [1] and uploaded
the package again to mentors [2].
Roland, can you have an other look onto the package, especially the new
parts [3] regarding the newly added php-twig-doc package?
Thanks
Daniel
[1] http://anonscm.debian.org/gitweb/?p=pkg-php/twig.git;a=summary
[2] https://mentors.debian.net/package/twig
[3]
http://anonscm.debian.org/gitweb/?p=pkg-php/twig.git;a=commit;h=ad3dc1376111f8351f8e905b9799d687b64713d1
signature.asc
Description: This is a digitally signed message part
Bug#645883: [pkg-php-pear] Bug#645883: Current status of twig
On Mon, 2014-05-05 at 12:12 +0200, Roland Mas wrote:
Daniel Beyer, 2014-05-04 23:44:03 +0200 :
Roland, can you have a look onto the package? Yann and I think it is
ready. You can find it on anonscm.d.o [1] or mentors [2]. Thanks a
lot!
I just did. The package looks almost ready, congrats :-)
The main nit I have is that the testsuite doesn't pass. When I run
pdebuild, the override_dh_auto_test target in debian/rules runs phpunit,
and phpunit fails one test with the following error:
,
| There was 1 failure:
|
| 1) Twig_Tests_IntegrationTest::testIntegration with data set #23
('expressions/ends_with.test', 'Twig supports the ends with operator', '',
array('
| {{ \'foo\' ends with \'o\' ? \'OK\' : \'KO\' }}
| {{ not (\'foo\' ends with \'f\') ? \'OK\' : \'KO\' }}
| {{ not (\'foo\' ends with \'foowaytoolong\') ? \'OK\' : \'KO\' }}'), false,
array(array('--DATA--
| return array()
| --EXPECT--
| OK
| OK
| OK', '
| return array()
| ', '', '
| OK
| OK
| OK')))
| Twig supports the ends with operator (in expressions/ends_with.test)
| Failed asserting that two strings are equal.
| --- Expected
| +++ Actual
| @@ @@
| 'OK
| -OK
| -OK'
| +KO
| +KO'
|
| /tmp/buildd/twig-1.15.1+dfsg/lib/Twig/Test/IntegrationTestCase.php:140
| /tmp/buildd/twig-1.15.1+dfsg/lib/Twig/Test/IntegrationTestCase.php:28
`
I'm not sure exactly what that means, but since the source package
generates an arch-specific binary package it's quite possible that the
autobuilders will fail on that. And regardless of the biuldds, it's
better if the testsuite passes.
Funny, the tests do not fail under wheezy(-backports), but they do fail
under jessie and sid (both with the error above). I'll try to take a
look at this in the evening.
Also, I found out that https://github.com/fabpot/Twig/issues/1118 is
now closed. It might make sense so update the packaging accordingly
(maybe add a new php-twig-doc binary package?).
Thanks for your efforts, this package is almost in shape!
Great, I guess I should go and thank some people like my colleague at
work for finally getting this resolved. I already have a variant laying
around that builds a -doc from the source, so this should not delay the
packing much.
Thanks a lot for you fast and valuable feedback.
--
Daniel
Swiss
signature.asc
Description: This is a digitally signed message part
Bug#645883: [pkg-php-pear] Bug#645883: Current status of twig
Roland, can you have a look onto the package? Yann and I think it is ready. You can find it on anonscm.d.o [1] or mentors [2]. Thanks a lot! Yann, please find my replies inline. On Sat, 2014-05-03 at 12:13 +0200, Yann Autissier wrote: Hi Daniel, I pushed two modifications to github : - rename the C extension package to php5-twig - update dependencies between packages as you mentionned Perfect and thanks a lot for updating the two README.Debian files. The packaging is quite complete and compiles properly. All seems fine to me. Great, so it does to me. Please note that I put the git repository onto anonscm.d.o [1], since this should makes it easier to group-maintain Twig within the Debian PHP PEAR Maintainers. I updated the vcs-fields in d/control to reflect the new location of the packaging repository. You may in future want to push directly to the repository there. [1] http://anonscm.debian.org/gitweb/?p=pkg-php/twig.git;a=summary [2] https://mentors.debian.net/package/twig signature.asc Description: This is a digitally signed message part
Bug#645883: [pkg-php-pear] Bug#645883: Current status of twig
On Tue, 2014-04-29 at 00:57 +0200, Yann Autissier wrote: Hi Daniel, I agree that twig should be provided as two separate packages for the C module and the PEAR extension, with a dependance between both. Currently php-twig only suggests the C module, while the C module recommends php-twig. Thinking about it, I guess more tight dependencies would be better, e.g: Let the C module depend on php-twig and have php-twig recommend the C module. I would rather have named the C module 'php5-twig', like other C modules. I agree. Do you have an account on github? I would happily add you to the current repo there, so you can directly push changes to it. But maybe the repo should be put onto alioth? @Roland, David: The instructions on php.debian.net how to upload a repo mentions a shell script alioth-new-git [1], which no longer seems to be around there. Btw.: My alioth account is dabe-guest. I will shortly test your packaging and give you some feedback. Great! In the meantime I recalled Twig from mentors.debian.net, since it obviously needs some more work. [1] http://php.debian.net/alioth-new-git.txt -- Daniel Swiss signature.asc Description: This is a digitally signed message part
Bug#645883: [pkg-php-pear] Bug#645883: Current status of twig
On Wed, 2014-04-29 at 09:24 +0200, Yann Autissier wrote: Here it is : https://github.com/aya Thanks, just added it. signature.asc Description: This is a digitally signed message part
Bug#645883: [pkg-php-pear] Bug#645883: Current status of twig
On Wed, 2014-04-23 at 23:28 +0200, Daniel Beyer wrote: On Wed, 2014-04-23 at 19:14 +0200, Daniel Beyer wrote: (...) * I'm almost done with switching the packing to git-buildpackage and will push this to github in the next few hours. I just pushed that to the repo on github [1] and dropped some no longer useful old branches. Additionally I locally build and uploaded the current status (as of 039273f) to mentors.debian.net [2]. Any feedback/review/improvements/suggestions/testing is always welcome. (...) [1] https://github.com/ymc/twig-debian [2] https://mentors.debian.net/package/twig Hi Yann, hi Laurent, what do you think about the way Twig currently is packaged? Should we proceed with the current packaging or are there reasons to re-think about or even abandon it? Sorry for pushing this, which might seems a bit strange after I cold-shouldered this ITP for quite some time. But now that David brought this up again and Roland pointed to a quite promising way for getting Twig into and maintaining it in Debian, I simply can't let loose of it. Btw: In recent commit 79878c9 [1] I dropped the dependency to devscript 2.13.5~ in favor of a newly added override_dh_testdir target in d/rules. The commit message explains my motivation for this, but I'm unsure if this really is something that should be done there. [1]https://github.com/ymc/twig-debian/commit/79878c9d3a48ffafb39d1aaeee588a88f8027eb7 Thanks Daniel signature.asc Description: This is a digitally signed message part
Bug#645883: [pkg-php-pear] Bug#645883: Current status of twig
On Wed, 2014-04-23 at 18:23 +0200, Roland Mas wrote: Hi all, As part of https://wiki.debian.org/DebianFrance/NewContributorGame#Twig_packaging I'd like to introduce you guys to one another. Yann and Laurent expressed interest in packaging Twig; from a cursory read of the bug log, Daniel seems to have preliminary packages; David is curious ; #645883 is where the discussion happens (and pkg-php-pear would like to be kept in touch); and yours truly is interested in seeing the package enter Debian and would gladly provide testing and sponsoring. Let's work together :-) Roland. That's totally great news for me and I'm really would enjoy working on that with all of you. To prevent you from digging through #645883 here is its current status: * There is a packaging on github [1], which I think is in a pretty good shape. * I'm almost done with switching the packing to git-buildpackage and will push this to github in the next few hours. * I (double) replaced the way the dfsg source is generated. In the current (just pushed) version it uses uscan's debian/copyright::Files-Excluded feature (first found in devscripts v2.13.5). * The licensing issue of Twig's documentation: This is now open for about 10 month. Short version is, that SensioLabs mentions two different licenses for Twig's documentation (see [2]). A co-worker of mine at YMC will meet with Andreas from SensioLabs Germany tomorrow and promised me to talk with him about that licensing thing. Therefore I have reason to believe this might get resolved soon. Btw: I have a version of the packaging, that additionally builds a -doc package from the source. But that one would need some more work to get it in a final shape. The last days I had time to play around with pkg-php-tools. The way of creating Debian packages from pear repositories is cool. Sadly, in my opinion, this can't be used for Twig, since we would end up with multiple source packages for Twig (one for Twig, one for Twig's PHP5 extension and probably an other one for the documentation). Reason for this is, that Twigs pear package [3] only provides the PHP code of Twig. The PHP5 extension is in a separate pear package and the documentation is not found on the pear channel at all (at least I did not see any traces of it). @David: I have a modified version of package pear-channels, that adds Twigs's pear channel - if you are interested in it. [1] https://github.com/ymc/twig-debian [2] https://github.com/fabpot/Twig/issues/1118 [3] http://pear.twig-project.org/ Sorry for the pretty longish summary, didn't intended to write that much... Greetings Daniel signature.asc Description: This is a digitally signed message part
Bug#645883: [pkg-php-pear] Bug#645883: Current status of twig
On Wed, 2014-04-23 at 19:14 +0200, Daniel Beyer wrote: (...) * I'm almost done with switching the packing to git-buildpackage and will push this to github in the next few hours. I just pushed that to the repo on github [1] and dropped some no longer useful old branches. Additionally I locally build and uploaded the current status (as of 039273f) to mentors.debian.net [2]. Any feedback/review/improvements/suggestions/testing is always welcome. (...) [1] https://github.com/ymc/twig-debian [2] https://mentors.debian.net/package/twig -- Daniel Swiss signature.asc Description: This is a digitally signed message part
Bug#645883: Updated wnpp info
Package: wnpp Severity: wishlist Owner: Daniel Beyer d...@deb.ymc.ch * Package name: twig Version : 1.15.1 Upstream Author : Fabien Potencier fab...@symfony.com * URL : http://twig.sensiolabs.org/ * License : BSD 3-Clause (New BSD) Programming Lang: PHP, C Description : Flexible, fast, and secure template engine for php Twig is a fast, secure and flexible template engine for php, implementing an own domain specific language which originated from Jinja and Django templates. It optionally can make use of a php5 extension, that enhances its performance. signature.asc Description: This is a digitally signed message part
Bug#645883: Current status of twig
Hi David, On Mon, 2014-04-21 at 15:14 -0400, David Prévot wrote: Hi Daniel, On Sun, Jun 30, 2013 at 07:32:35PM +0200, Daniel Beyer wrote: I just wanted to inform you that I just opened an RFS (request for sponsorship) for Twig (see: #714548). Unfortunately, it looks like this report has been closed before someone got a chance to look at your package. I guess I totally failed to reach out to an audience interested in twig with just targeting the mentors list with that RFS. But I'm very happy you just stumbled about that old RFS of mine. Great! [2] https://github.com/ymc/twig-debian/ I just had a pretty quick look at it: you may wish to rename your main binary package as php-twig, maintain it within the Debian PHP PEAR Maintainers team, and follow its usage: build with pkg-php-tools, and use a pkg-php repository on Alioth, etc. http://php.debian.net/ https://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-pear I think team-maintaining twig withing the Debian PHP PEAR Maintainer team is the way to go. I'll check out what needs to be done to get Twig packaged with pkg-php-tools. Additionally I'll nudge SensioLabs once again, since they still owe me a statement regarding the license of Twig's documentation. Since I'm not a DD I can't grant myself access to an pkg-php repository for twig on a Debian server. But I guess using the repo on github a bit longer is not an issue at all. Thanks in advance. Regards David Thanks for the poke :-) -- Daniel Swiss signature.asc Description: This is a digitally signed message part
Bug#645883: Current status of twig
Hi Paul, hi Guillaume I just wanted to inform you that I just opened an RFS (request for sponsorship) for Twig (see: #714548). This is needed, since I'm not a DD (Debian developer) and therefore can not upload new packages to Debian on my own. I decided to drop out Twig's documentation and the binary package twig-doc, since upstream so far ignored my question regarding the licensing of the documentation [1]. I'll check out, if I can use our companies contacts with SensioLabs Germany, to get some attention onto this issue. Once the licensing of the documentation has been clarified, I'll re-add it to the source together with the resulting binary package twig-doc. For this purpose I keep a branch in sync on Github [2]. Once again, thanks a lot for all of your feedback and your initial work on the twig-packaging for Debian. [1] https://github.com/fabpot/Twig/issues/1118 [2] https://github.com/ymc/twig-debian/tree/feature/re-add-twig-doc -- Daniel Swiss signature.asc Description: This is a digitally signed message part
Bug#645883: ITP #645883 - Under which license you intended to release the Debian packaging of twig
Hi Guillaume, so far you did not response to my question regarding the license you want to put your original work [1] under. Since Paul based his work on yours, we need a statement from you regarding the licensing. Paul suggested the MIT license [2], which would be fine for me. Do you agree using this one? It would be great if you find the time to answer! Thanks in advance Daniel [1] https://github.com/Guillaumito/twig-package [2] http://opensource.org/licenses/MIT signature.asc Description: This is a digitally signed message part
Bug#645883: ITP #645883 - Under which license you intended to release the Debian packaging of twig
Am Donnerstag, den 20.06.2013, 10:06 +0200 schrieb Guillaume Duhamel: It would be great if you find the time to answer! Sorry for not replying to previous mails :) No problem, thanks a lot for answering this one! I don't mind much the licensing terms for my work on Twig package, so if Paul wants MIT, it's ok for me. Great, so we all agree using MIT for the packaging. It's been some time I worked on this package, but at the time I created another repository: https://github.com/Guillaumito/twig-gbp using debian git-buildpackage. Is it useful? Thanks for sharing this information. It might would have been useful, but I think the new packaging [1] based on Paul's repository is already pretty final. The main thing currently holding twig back is an issue [2] with the licensing of twig's documentation. I hope upstream will answer my question on github soon, since I don't like the idea of dropping twic-doc out. [1] https://github.com/ymc/twig-debian/tree/feature/reprocess-initial-debian-packaging [2] https://github.com/fabpot/Twig/issues/1118 Guillaume -- Daniel Swiss signature.asc Description: This is a digitally signed message part
Bug#645883: Updated wnpp info
Package: wnpp Severity: wishlist Owner: Daniel Beyer d...@deb.ymc.ch * Package name: twig Version : 1.13.1 Upstream Author : Fabien Potencier fab...@symfony.com * URL : http://twig.sensiolabs.org/ * License : BSD 3-Clause (New BSD) Programming Lang: PHP, C Description : Flexible, fast, and secure template engine for PHP Twig is a modern template engine for PHP Fast: Twig compiles templates down to plain optimized PHP code. The overhead compared to regular PHP code was reduced to the very minimum. Secure: Twig has a sandbox mode to evaluate untrusted template code. This allows Twig to be used as a template language for applications where users may modify the template design. Flexible: Twig is powered by a flexible lexer and parser. This allows the developer to define its own custom tags and filters, and create its own DSL. signature.asc Description: This is a digitally signed message part
Bug#645883: Are you still working on #645883 - ITP: twig -- Template engine for PHP
Hi Paul, you opened the ITP #645883 in late 2011 with the last notable activity in the end of 2012. Are you still working on bringing twig into Debian? If not, I would be happy to takeover your ITP as well as your existing work with the packaging. Additionally it would be possible for me to regularly invest the time to maintain the package later on, should it be accepted in Debian. Thanks in advance for your feedback. -- Daniel Swiss signature.asc Description: This is a digitally signed message part
Bug#645883: Are you still working on #645883 - ITP: twig -- Template engine for PHP
Am Donnerstag, den 13.06.2013, 17:43 +0100 schrieb Paul Waring: I don't know what to do next - hence the last comment. I don't mind if you want to take over from where I've got to or start afresh. No need to start from scratch, but the current packaging needs some love in order to have a chance of being accepted in Debian - I forked your repository on github and started with that. If you like, we can try bringing twig into Debian together. I really would enjoy forming a team for this and (if possible for you) co-maintaining the package later on. -- Daniel Swiss signature.asc Description: This is a digitally signed message part
Bug#645883: ITP #645883 - Under which license you intended to release the Debian packaging of twig
Hi Paul, hi Guillaume, there is some source regarding the Debian packaging of twig at: https://github.com/pwaring/twig-debian Under which license you intended to release the source involved in the packaging? If you unsure, I suggest either using the GPL-3+ (which means the GNU General Public License 3.0 or any later version of it) or a BSD-style license (similar to the one twig itself uses). -- Daniel Swiss signature.asc Description: This is a digitally signed message part
Bug#706204: ITP: sgabios -- A bios option rom to provide legacy serial console for x86
Package: wnpp Severity: wishlist Owner: Daniel Beyer d...@deb.ymc.ch * Package name: sgabios Version : 2010.04.22 Upstream Author : Nathan Laredo n...@google.com * URL : https://code.google.com/p/sgabios/ * License : Apache-2.0 Programming Lang: C Description : A bios option rom to provide legacy serial console for x86 The Google Serial Graphics Adapter BIOS or SGABIOS provides a means for legacy x86 software to communicate with an attached serial console as if a video card were attached. SGABIOS is designed to be inserted into a BIOS as an option rom to provide over a serial port the display and input capabilities normally handled by a VGA adapter and a keyboard. SGABIOS can be used to feature OS independent serial console redirection in Qemu. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426094109.22381.75148.reportbug@d1-t20.cluster
