On Sun, Sep 22, 2024, 04:30 Alexandre Detiste
wrote:
> Hi,
>
> I've finally finished updating python3-consul.
>
> I realise consol.io itself is not packaged in Debian
> (and there's no ITP/RFP).
>
As a prior packager of consul in Debian, https://bugs.debian.org/1055054 is
relevant (I don't belie
On Wed, 22 Dec 2021 at 00:04, Lucas Nussbaum wrote:
> Source: hy
> Version: 0.19.0-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20211220 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to
On Tue, 5 May 2020 at 10:55, Tianon Gravi wrote:
> I was definitely over my head with this one, so I reached out to the
> Hy community and was pointed to https://bugs.python.org/issue39562,
> which does seem quite related from my own limited understanding, so
> this might technically
On Sun, 3 May 2020 at 06:12, Lucas Nussbaum wrote:
> > ...
> > === warnings summary
> > ===
> > .pybuild/cpython3_3.8_hy/build/tests/native_tests/comprehensions.hy::test_fors[sfor]
> > /<>/hy/models.py:133: RuntimeWarning: coroutine ''
>
On 21 January 2016 at 07:10, Harlan Lieberman-Berg wrote:
> I'd like to request to join this team to help maintain backports of the Let's
> Encrypt dependencies, especially python-sphinx.
>
> I've read and agree to the Python Modules Team Policy. My Alioth username is
> hlieberman-guest.
I can'
On 20 April 2015 at 20:21, Potter, Tim (Cloud Services)
wrote:
> It looks pretty good, but I think I have messed up something as my binary
> gives an import error since /usr/share/dwarf isn’t in the PYTHONPATH:
>
> # dwarf
> Traceback (most recent call last):
> File "/usr/bin/dwarf", line 32, i
On 31 March 2015 at 17:38, Daniel Lintott wrote:
> Well the software I'm packaging requires aiohttp so there is definitely
> interest in having it available in Debian!
>
> Personally I don't have time to take the maintenance of aiohttp on myself, so
> if you're happy to maintain it that would be
On 31 March 2015 at 07:24, Daniel Lintott wrote:
> I can't find an ITP/RFP bug for the package, but see that there are some
> files already in SVN.
I was packaging it originally for something paultag was working on,
but he no longer needed it so I didn't finish (and it felt like a
waste to just p
On 4 February 2015 at 15:18, Ben Finney wrote:
> Great! Can we please have (from you, or whoerver is best position to
> write it) a reference on how to use this redirector?
Checking out http://pypi.debian.net/hy, it looks pretty easy to use. :)
♥,
- Tianon
4096R / B42F 6819 007F 00F8 8E36 4FD
On 4 February 2015 at 13:06, Donald Stufft wrote:
> We talked about this in #debian-python and there was concern that a new
> version
> of uscan wouldn’t be in Jessie and then wouldn’t cover the people who need it
> the most.
Ah right, that makes sense -- I forgot that we were talking about this
On 4 February 2015 at 06:08, Donald Stufft wrote:
> If it gets implemented it'll live at /uscan/ because it exists primarily to
> work around the deficiencies that exist in uscan (Particularly the dificulty
> in ignoring url fragments).
This seems like we're building a workaround to a tool we cou
On 13 November 2014 10:25, Daniele Tricoli wrote:
> I'm working on this and I think I have already the proper fix. Sorry for this!
> :(
No worries from my end! Thanks for your work! :D
♥,
- Tianon
4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
--
To UNSUBSCRIBE, email to debian-
On 12 November 2014 23:43, Tianon Gravi wrote:
> I reverted the python-docker -1.1 patch (and I've pushed that up so
> it's easier to test against), ...
Of course, that's the moment where my local push decides to hang and
make a liar out of me... O:)
♥,
- Tianon
4096R
On 12 November 2014 15:15, Daniele Tricoli wrote:
> All done, including unblocking by RT (you rock! :). Many thanks to all!
I reverted the python-docker -1.1 patch (and I've pushed that up so
it's easier to test against), and now it works perfectly in python2
using the new requests 2.4.3-3, but p
On 9 October 2014 22:59, Ben Finney wrote:
> It's a good illustration of why I much prefer the workflow of a separate
> VCS for the ‘debian/’ directory, merged with upstream source only at
> build time. The results of the merge are in a separate location and are
> never checked into VCS, they're u
On 10 September 2014 11:11, Piotr Ożarowski wrote:
> yes (and I'm still wondering if failing with an error message that this
> module name is too generic is a better idea)
I'd personally love to see it hard fail (since warnings will be quite
often missed), especially if it included some hints abo
On 9 September 2014 09:28, Piotr Ożarowski wrote:
> (I will remove all .../dist-packages/test{,s} by default in next
> dh_python{2,3} version).
Does this mean we'll get a nice warning too, so we know that we need
to report the bug upstream? :)
♥,
- Tianon
--
To UNSUBSCRIBE, email to debian-pyt
On 18 August 2014 18:11, Brian May wrote:
> Unfortunately, debian/watch (AFAIK) doesn't include any details of any
> changes that were made to the tar.gz file by the package developer.
It's been my understanding that this is exactly one of the main uses of
the "command" argument in debian/watch.
On 18 August 2014 17:52, Brian May wrote:
> I take this to mean I should be downloading the orig.tag.gz from github.
Not that I'm involved in the packaging or the upstream here in any
way, but I just wanted to point out that this is exactly what
"debian/watch"[1] is for, which uscan(1) will read
Hi! :)
I'm part of the docker-maint team (which is listed in Uploaders on
python-docker), and I'm interested in joining DPMT to help Paul maintain
and update python-docker, which is falling a little bit behind upstream.
♥,
- Tianon
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian
20 matches
Mail list logo