On Mon, Mar 24, 2025 at 06:33:19PM +, Helge Kreutzmann wrote:
Am Mon, Mar 24, 2025 at 05:49:40PM +0100 schrieb Marc Haber:
"Using no line numbers" => invoke msgmerge with --no-location?
Yes.
"Web pages mentioned above" => I don't see web pages being mentioned. That
needs a name or a link
Hello Marc,
Am Mon, Mar 24, 2025 at 05:49:40PM +0100 schrieb Marc Haber:
> On Sat, Mar 22, 2025 at 06:32:54PM +, Helge Kreutzmann wrote:
> > Am Wed, Mar 19, 2025 at 09:44:47AM +0100 schrieb Marc Haber:
> > If you have any questions on my changes it is probably best to discuss
> > this on list.
Hello Marc,
Am Wed, Mar 19, 2025 at 09:44:47AM +0100 schrieb Marc Haber:
> tl;dr: New Wiki Page https://wiki.debian.org/I18n/ForPackageMaintainers,
> please review
I just did it. I usually updated it right away, but at one or two
points it is more like a discussion. And due to my changes some
redu
ul. I
hope that this rant will start a positive discussion with actual results
that I could pour into a Wiki page that might actually help with the
pain I am feeling, assuming that many other maintainers feel as well.
Sadly, the disusscion didn't really get traction. But there was
valuea
On Tue, Jan 14, 2025 at 08:52:39AM +0100, Philip Hands wrote:
> I'd really like to know how it is possible for one to use an LLM to make
> a contribution to a permissively licensed project (e.g. Expat) without
> in effect stealing the code from one's own tribe of Copyleft authors.
>
> Can one even
"M. Zhou" writes:
> On Sun, 2025-01-12 at 16:56 +, Colin Watson wrote:
>>
>> (I have less fixed views on locally-trained models, but I see no very
>> compelling need to find more things to spend energy on even if the costs
>> are lower.)
>
> Locally-trained models are not practical in the cu
On Sat, Jan 11, 2025 at 11:25:20AM -0500, M. Zhou wrote:
> On Sat, 2025-01-11 at 13:49 +0100, Fabio Fantoni wrote:
> >
> > Today trying to see how a new person who wants to start maintaining new
> > packages would do and trying to do research thinking from his point of
> > view and from simple s
On 2025-01-12 at 18:03 +, Andrew M.A. Cater wrote:
> Watching other people find and fix bugs, even in code they
> have written or know well, I can't trust systems built on modern
> Markov chains to do better, no matter how much input you give them, and
> that's without crediting LLMs as able to
On Sun, 2025-01-12 at 16:56 +, Colin Watson wrote:
>
> (I have less fixed views on locally-trained models, but I see no very
> compelling need to find more things to spend energy on even if the costs
> are lower.)
Locally-trained models are not practical in the current stage. State-of-the-art
On Sun, Jan 12, 2025 at 04:56:15PM +, Colin Watson wrote:
> On Sat, Jan 11, 2025 at 07:13:58PM -0800, Otto Kekäläinen wrote:
> > I don't think Debian should as an organization pay for LLMs. On the
> > contrary I would expect LLM providers to offer API keys for free to
> > Debian Developers just
On Sat, Jan 11, 2025 at 07:13:58PM -0800, Otto Kekäläinen wrote:
> I don't think Debian should as an organization pay for LLMs. On the
> contrary I would expect LLM providers to offer API keys for free to
> Debian Developers just like we have other perks listed at
> https://wiki.debian.org/MemberBe
...
> Debian should consider allocating some budget like several hundred USD
> per month for the LLM API calls for all members and new-comers' usage.
I don't think Debian should as an organization pay for LLMs. On the
contrary I would expect LLM providers to offer API keys for free to
Debian Devel
On Sat, 11 Jan 2025 18:04:15 +0500, Andrey Rakhmatullin wrote:
> Yeah, not sure if that's your point but I think everyone agrees that we
> need a good new packager document and while there were some attempts in
> the past (see links on https://mentors.debian.net/intro-maintainers
to
these tool man pages are reviewed by the tool maintainers and thus
likely end up in man pages that are actually correct. Sending MRs to
the tool maintainers likely also helps them stay motivated to continue
to maintain the tools, and the MR contents helps the maintainers get
insight of the "user
On Sat, Jan 11, 2025 at 11:25:20AM -0500, M. Zhou wrote:
> Opinion against this post will include something about hallucination.
> In the case LLM write something that does not compile at all, or write
> some non-existent API, a human is intelligent enough to easily notice
> that build failure or l
s on git(even if not
salsa). It is faster to review, comment specifically, and possibly help
fix/improve directly.
Another difference for maintainers can be managing Debian patches, in
many cases they are not needed but where they are needed there can be
also a good difference in the time that c
On Sat, Jan 11, 2025 at 03:38:10PM +, Ahmad Khalifa wrote:
> > Write on Google "Debian create new package" and first result: https://
> > wiki.debian.org/HowToPackageForDebian
> >
> > It points to various parts but mainly the more probable start point
> > seems https://wiki.debian.org/Packagin
On Sat, 2025-01-11 at 13:49 +0100, Fabio Fantoni wrote:
>
> Today trying to see how a new person who wants to start maintaining new
> packages would do and trying to do research thinking from his point of
> view and from simple searches on the internet I found unfortunately that
> these parts a
On 11/01/2025 12:49, Fabio Fantoni wrote:
Write on Google "Debian create new package" and first result: https://
wiki.debian.org/HowToPackageForDebian
It points to various parts but mainly the more probable start point
seems https://wiki.debian.org/Packaging/Intro
To point to git and gbp see
;reference implementation" out of a carefully chosen
project, and publish a frozen demo git repository that could be cloned
and used along the tutorial.
Practices that are specific to teams or maintainers should be documented
by them, as they are in the best place to know what is current and wh
n and help (even on
> mentors, although it seems to have improved recently)
Yeah, not sure if that's your point but I think everyone agrees that we
need a good new packager document and while there were some attempts in
the past (see links on https://mentors.debian.net/intro-maintainers/ )
ther
There has been a lot of talk about attracting and helping new
maintainers, some improvements have been made "here and there", the
documentation of gbp (the most used tool) has been improved, salsa,
salsa-ci have been improved, there is discussion about DEP18, accepting
DEP14 etc..
Hi,
On Thu, 3 Oct 2024, at 23:08, Jonas Smedegaard wrote:
> Quoting Andrej Shadura (2024-10-03 21:41:49)
>> On Thu, 3 Oct 2024, at 20:05, Debian FTP Masters wrote:
>> >* simplify rules;
>> > build-depend on dh-rust (not dh-cargo);
>> > add X-Cargo-Crates hint;
>> > drop patch de
Quoting Jonas Smedegaard (2024-10-03 23:08:38)
> Quoting Andrej Shadura (2024-10-03 21:41:49)
> > Hi Jonas,
> >
> > Thanks for helping with maintaining Synapse.
> >
> > I appreciate that you did some valuable work, but it would be great if you
> > gave me a heads-up before uploading. While we’re
Quoting Andrej Shadura (2024-10-03 21:41:49)
> Hi Jonas,
>
> Thanks for helping with maintaining Synapse.
>
> I appreciate that you did some valuable work, but it would be great if you
> gave me a heads-up before uploading. While we’re both members of the team,
> and it’s true I haven’t had tim
On Sun, Mar 17, 2024 at 06:53:34AM +0100, Emanuele Rocca wrote:
>
> On 2024-03-16 04:21, Emanuele Rocca wrote:
> > With libcurl3t64-gnutls cargo can now be rebootstrapped on armhf
>
> And on armel too. Fixed armhf/armel packages uploaded.
>
> > Fabian: it seems that cargo's build-depend on git c
Am 01.02.24 um 09:30 schrieb Steve Langasek:
What is the rationale behind rising a bug report at 9:51pm my time and
firing a *direct* NMU upload just 11min later (according to the time stamps
from the emails)?
There are 1200+ source packages that require NMUing and the Debian archive
is a movi
mentioned from the initial email again, also there I
> can't find a written plan that would explain me why the bug reporting
> together with a direct upload did happen. I see no plan there what will
> happen on what time.
> Why no usual muss bug filling did happen so groups and maintainer
On 2024-02-01, Carsten Schoenert wrote:
> What is the rationale behind rising a bug report at 9:51pm my time and
> firing a *direct* NMU upload just 11min later (according to the time
> stamps from the emails)?
> I as the uploader for libcoap have no chance to do any action on this
> bug report
initial email again, also there
I can't find a written plan that would explain me why the bug reporting
together with a direct upload did happen. I see no plan there what will
happen on what time.
Why no usual muss bug filling did happen so groups and maintainers would
have some know
On Sun, Jan 21, 2024 at 10:52:02AM +0100, Jonas Smedegaard wrote:
> I can offer to maintain hosting and packaging of debtags code projects.
> Would that be helpful, or are/were you looking for new code maintainer?
Thank you for your interest! Personally I am not motivated to look after
Debtags an
Hi Enrico (cc d-devel list),
Quoting Enrico Zini (2022-10-19 15:20:43)
> I would like to let go of the responsibility of maintaining
> debtags.debian.org.
>
> Over the years I did my best to simplify the whole system, so picking up
> maintenance shouldn't be too hard, if there is interest.
>
> I
On Wed, 2023-02-08 at 05:52 -0600, Brian Thompson wrote:
> On Tue, 2023-02-07 at 14:23 +0100, Andrej Shadura wrote:
> > Package: wnpp
> > Severity: normal
> > X-Debbugs-Cc: debian-devel@lists.debian.org
> >
> > Hi all,
> >
> > I packaged SoftEther VPN back in 2020 when people in Belarus protested
On Tue, 2023-02-07 at 14:23 +0100, Andrej Shadura wrote:
> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: debian-devel@lists.debian.org
>
> Hi all,
>
> I packaged SoftEther VPN back in 2020 when people in Belarus protested
> against decades of
> dictatorship, and they needed a safe way to comm
Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-devel@lists.debian.org
Hi all,
I packaged SoftEther VPN back in 2020 when people in Belarus protested against
decades of dictatorship, and they needed a safe way to communicate with the
outside world and with each other, circumventing the stat
Hello,
I would like to let go of the responsibility of maintaining
debtags.debian.org.
Over the years I did my best to simplify the whole system, so picking up
maintenance shouldn't be too hard, if there is interest.
I'm going to keep the service in life support until bookworm releases,
and if n
Hi,
Hi,
On Tue, 28 Sep 2021, at 08:29, Richard Laager wrote:
I don't think we should install something
like netplan by default.
I agree: it only adds complexity.
I personally use netplan everywhere.
As to what should be the distro default, I'm not sure I am convinced
either way, but to a
Your message dated Thu, 30 Jul 2020 13:09:35 +0200
with message-id <20200730110934.ouliun7sqpsf2...@percival.namespace.at>
and subject line Re: Bug#859877: debian-maintainers: problem mit instalation HP
DeskJet 2130 all-in-one
has caused the Debian Bug report #859877,
regarding debian-maint
On Wed, Feb 13, 2019 at 05:17:27PM +0100, Ansgar wrote:
> More important is the question if the system should /trust/ the keys.
>
> IMHO installing a non-Debian keyring should *not* make the keys trusted
> by APT by default (i.e. with the default answer if debconf is used).
I've agreed, it's the
Quoting Linda Lapinlampi (2019-02-13 16:41:06)
> On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote:
> > Quoting Jonas Smedegaard (2019-02-12 19:38:57)
> > > I believe this package belongs in contrib, as its only use-case is
> > > with together with software outside of Debian main.
>
On Wed, Feb 13, 2019 at 05:17:27PM +0100, Ansgar wrote:
> More important is the question if the system should /trust/ the keys.
>
> IMHO installing a non-Debian keyring should *not* make the keys trusted
> by APT by default (i.e. with the default answer if debconf is used).
agreed.
> ubuntu-keyr
On Wed, 2019-02-13 at 15:41 +, Linda Lapinlampi wrote:
> Template: matrix-archive-keyring/sources.list
> Type: boolean
> Default: false
> _Description: Use APT data sources from Matrix.org?
> The Matrix.org Debian package repository distributes supplemental Matrix.org
> related packages inten
On Tue, Feb 12, 2019 at 09:40:30PM +0100, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2019-02-12 19:38:57)
> > I believe this package belongs in contrib, as its only use-case is with
> > together with software outside of Debian main.
>
> ...and now posting to the actual bugreport as well.
Quoting Jonas Smedegaard (2019-02-12 19:38:57)
> [ adding d-devel@ to the discussion ]
>
> Quoting Linda Lapinlampi (2019-02-12 18:51:39)
> > The Matrix.org Debian package repository distributes digitally signed
> > releases of Matrix.org related packages. This package contains the
> > archive k
[ adding d-devel@ to the discussion ]
Quoting Linda Lapinlampi (2019-02-12 18:51:39)
> The Matrix.org Debian package repository distributes digitally signed
> releases of Matrix.org related packages. This package contains the
> archive key used to verify those files, required by apt(8).
I belie
Andreas Henriksson writes ("Re: Policy and procedures issue: init package
hijacked via hostile NMU (declined by maintainers)"):
> I have only seen a limited amount of Dmitrys work, but my impression
> is that he's not someone who should be trusted with unrestricted
> uploa
On Sat, Dec 22, 2018 at 10:11:53AM -0800, Josh Triplett wrote:
> Please note in the following mail that I'm raising this *exclusively* as a
> policy and procedures issue, *not* a technical issue. I would request that
> people *please* focus on the policy and procedures issue, and keep any
> propos
On Sat, 2018-12-22 at 22:51:37 +, Simon McVittie wrote:
> On Sat, 22 Dec 2018 at 22:25:48 +0100, Guillem Jover wrote:
> > Procedurally? I guess it was
> > OKish, but I guess that's a consequence we get when people involved
> > the ctte to muddle the social and procedural fabric of the project…
On Sat, 22 Dec 2018 at 22:25:48 +0100, Guillem Jover wrote:
> Procedurally? I guess it was
> OKish, but I guess that's a consequence we get when people involved
> the ctte to muddle the social and procedural fabric of the project…
I am not aware of any requests for decisions, requests to overrule
l the NMU *himself*.
> [...]
> He also said the maintainers had to get the CTTE to overrule
> his decision if they did not want to accept his NMU.
Not quite. Here are the relevant quotes:
,---
[2018-11-28 18:48] Dmitry Bogatov
> I am worried: freeze is coming, and noth
gt; - Dmitry refused to cancel the NMU, which then went into the archive.
>
> Dimitry refused to cancel the NMU *himself*.
[...]
He also said the maintainers had to get the CTTE to overrule
his decision if they did not want to accept his NMU.
(which apart from refusing to listen
itry reported back that it "works for him", and no further debugging
> appears to have taken place.
Dimitry sent another mail asking for a reproducer in the form of a VM or
similar. And mentioned being worried about missing the freeze deadline.
> - Dmitry uploaded an NMU to DELAYED
ystem installed
with runit-init appears broken, and in particular appears to hang
without any ability to log in.
- Dmitry reported back that it "works for him", and no further debugging
appears to have taken place.
- Dmitry uploaded an NMU to DELAYED/15.
- One of the maintainer
On Tue, Aug 15, 2017 at 8:00 PM, Berry A.W. van Halderen
wrote:
> On 31 July 2017, Ondřej Surý wrote:
>> I am looking for a new maintainer for opendnssec and softhsm package.
>> Honestly, I am not using neither, and it's quite hard to do a packaging
>> when you don't use the packages in question,
Hi,
On 07/11/2017 09:38, Thomas Goirand wrote:
> On 11/06/2017 09:56 AM, b...@coldsource.net wrote:
>> Hi everyone,
>>
>> I work for UFC - Que Choisir (a French consumer association) and we just
>> released (GPL3) version 2.0 of our job scheduler evQueue.
>>
>> Here is the website : http://www.ev
On 11/06/2017 09:56 AM, b...@coldsource.net wrote:
> Hi everyone,
>
> I work for UFC - Que Choisir (a French consumer association) and we just
> released (GPL3) version 2.0 of our job scheduler evQueue.
>
> Here is the website : http://www.evqueue.net/
>
> We are providing debian packages (debia
Hi everyone,
I work for UFC - Que Choisir (a French consumer association) and we just
released (GPL3) version 2.0 of our job scheduler evQueue.
Here is the website : http://www.evqueue.net/
We are providing debian packages (debian 8 and 9) but would like to know
if it is possible to get some
Yao Wei:
> Hi,
>
> There are some problems for us to package Debian packages for
> WebExtensions that can support Firefox and Chromium using the same
> codebase. I do come up with my idea, but I still need a conclusion to
> prepare a package:
>
> 1. Should we use different prefix for the WebExte
On 31 July 2017, Ondřej Surý wrote:
> I am looking for a new maintainer for opendnssec and softhsm package.
> Honestly, I am not using neither, and it's quite hard to do a packaging
> when you don't use the packages in question, and I think the package
> suffer as a consequence, and I very much dis
stretch (next stable) end-of-life and becomes
> maintainers.
Well, that's hard to promise, but I'll try to get courier ready for
stretch, in the first place. If that effort isn't successful, it should
better be dropped from stretch.
> Please note that the bug list on src:cour
On Tue, Jan 24, 2017 at 4:30 AM, Josh Triplett wrote:
> How long does it typically take for that to sync to
> https://packages.debian.org/unstable/ and (for instance)
The descriptions for that are hardcoded in lib/Packages/Sections.pm,
you might want to submit an update for the master branch of t
On Mon, Jan 23, 2017 at 08:56:31PM +0100, Ansgar Burchardt wrote:
> Josh Triplett writes:
> > Given that, can you please go ahead and add the two new sections for
> > rust (https://bugs.debian.org/845576) and javascript
> > (https://bugs.debian.org/753480), and update the override file for
> > exis
> Did you document your attempts so people willing to help have a point
> to start from?
No, and all the blame for that goes to me.
BTW the same holds for all of my other packages, I'm more than willing
to accept help/co-maintainership.
Thanks for the patch.
Michael
--
Michael Meskes
Michael
Hi,
TL;DR I am looking for prospective courier-mta maintainers for Courier
MTA packages.
a little history - Mark Constable asked me a while ago if I could
prepare updated Courier MTA packages for Ubuntu PPA. As a part of that I
whipped the courier-authlib, courier-unicode and courier packages up
On Sun, Dec 04, 2016 at 01:14:42PM +0100, Christoph Biedl wrote:
>...
> To add a few criteria, I'd remove a package from sid only if it
>...
> * has been orphaned for a longer time, say: a year
> So again users of that package had a grace period to ask for work on
> that package.
>...
Two ques
Michael Meskes wrote...
> Sure, but then it would be nice if you'd tried finding out if nobody
> cares. As usual the real world is neither white not black, but some
> shade of gray. The problem with the package is that the new version
> does not build on my system but I lack the time to debug, cou
Emilio Pozuelo Monfort wrote...
> I would suggest to come up with some algorithm to determine if a package is
> effectively unmaintained, and implement it in an automatic way that gives
> maintainers prior notice and a chance to react, like we do with auto-removals.
> Then if nothing
> > The question is absolutely valid, but maybe I should rephrase it to
> > "Why
> > are you contacting the uploader only and not the team as well?"
>
> Because it's the first step.
Would have been nice to know. Anyway, I can see your point.
> > > * Also: what should we do with packages that are
On Sat, Dec 03, 2016 at 09:25:11AM +0100, Michael Meskes wrote:
> > human maintainer". 1 was "why are you asking me, I am only an
> > uploader,
> > the package is team maintained" even though that person was the only
> > actual uploader (since 2002 till 2012). I've sent the list of my
> > pings to
On Sat, Dec 03, 2016 at 06:23:17PM +0500, Andrey Rahmatullin wrote:
> > I think we should also have an auto-removals-from-sid[1] (the crowd
> > applauded
> > when I mentioned that in my Debconf talk), which would solve/help your high
> > number of orphaned packages.
> What real problems will this
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote:
> I think we should also have an auto-removals-from-sid[1] (the crowd applauded
> when I mentioned that in my Debconf talk), which would solve/help your high
> number of orphaned packages.
What real problems will this solve apa
On Sat, Dec 03, 2016 at 11:42:02AM +0100, Mattia Rizzolo wrote:
> And: you're suggesting to do a QA upload without changing maintainer
> field? That seems ridiculous to me: QA uploads are uploads where
> maintainer is QA, right? You're suggesting to change the meaning to
> "big NMU", basically?
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote:
> I would suggest to come up with some algorithm to determine if a package is
> effectively unmaintained, and implement it in an automatic way that gives
> maintainers prior notice and a chance to react, like we do
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote:
> I would suggest to come up with some algorithm to determine if a package is
> effectively unmaintained, and implement it in an automatic way that gives
> maintainers prior notice and a chance to react, like we do
t's just plain hard/impossible to give an
> appropriate answer good for all cases. We shall discuss this again at
> DebConf instead.
I would suggest to come up with some algorithm to determine if a package is
effectively unmaintained, and implement it in an automatic way that gives
maintain
On Fri, Dec 02, 2016 at 10:56:07PM +0500, Andrey Rahmatullin wrote:
> * So, the first question is: should I spend my time on getting these
> packages back to testing so they would be a part of the next release? Or
> should I spend my time on other RC bugs fixing which will help release
> stretch fa
> human maintainer". 1 was "why are you asking me, I am only an
> uploader,
> the package is team maintained" even though that person was the only
> actual uploader (since 2002 till 2012). I've sent the list of my
> pings to
> the MIA team.
I don't like the way you are picturing this. The question
Andrey Rahmatullin writes ("Re: MIA maintainers and RC-buggy packages"):
> On Fri, Dec 02, 2016 at 06:58:55PM +, Ian Jackson wrote:
> > Frankly, I would have been tempted to let a lot of those packages slip
> > out of stretch. It depends what they were, of course
On Fri, Dec 02, 2016 at 06:58:55PM +, Ian Jackson wrote:
> > * So: is it a real problem that there are packages that should be marked
> > as orphaned but they aren't? Should we spend any effort on marking more
> > orphaned packages? If yes, how should we do that?
>
> No, I think this is a wast
Andrey Rahmatullin writes ("MIA maintainers and RC-buggy packages"):
> * So: is it a real problem that there are packages that should be marked
> as orphaned but they aren't? Should we spend any effort on marking more
> orphaned packages? If yes, how should we do that?
No,
should I spend my time on other RC bugs fixing which will help release
stretch faster?
Next, I contacted all maintainers or such packages, telling them that
their package X had its last maintaner upload on X and has an RC bug #X
since X, asking them to orphan the package if they are not interest
On 15.09.2016 22:43, Helge Deller wrote:
> Hi Matthias,
>
> On 10.09.2016 00:48, Matthias Klose wrote:
>> While the Debian Release team has some citation about the quality of the
>> toolchain on their status page, it is not one of the release criteria
>> documented
>> by the release team. I'd li
Hi Matthias,
On 10.09.2016 00:48, Matthias Klose wrote:
> While the Debian Release team has some citation about the quality of the
> toolchain on their status page, it is not one of the release criteria
> documented
> by the release team. I'd like to document the status how I do understand it
>
On Sat, Sep 10, 2016 at 09:21:42AM +0100, Simon McVittie wrote:
> On Sat, 10 Sep 2016 at 00:48:09 +0200, Matthias Klose wrote:
> > The arm-linux-gnueabi is not that well defined, so it may include the hard
> > float
> > variant as well. However Debian default to armv4t, while the default
> > conf
On 10.09.2016 09:59, Paul Gevers wrote:
> Hi,
>
> On 10-09-16 00:48, Matthias Klose wrote:
>> - fpc not available on powerpc anymore (may have changed recently)
>
> For whatever it is worth, this was finally fixed this week. It is
> missing on mips*, ppc64el and s390x though, while at least some
On 10.09.2016 10:21, Simon McVittie wrote:
> On Sat, 10 Sep 2016 at 00:48:09 +0200, Matthias Klose wrote:
>> The arm-linux-gnueabi is not that well defined, so it may include the hard
>> float
>> variant as well. However Debian default to armv4t, while the default
>> configuration for upstream is
On 09/10/2016 12:48 AM, Matthias Klose wrote:
> Uncovered by the upstream primary and secondary platforms are the mips*
> architectures and powerpc. For the uncovered archs I would expect somehow
> more
> and pro-active Debian maintenance, however I fail to see this happen.
>
> - see the histor
On Sat, 10 Sep 2016 at 00:48:09 +0200, Matthias Klose wrote:
> The arm-linux-gnueabi is not that well defined, so it may include the hard
> float
> variant as well. However Debian default to armv4t, while the default
> configuration for upstream is armv5. However with the selected defaults
> Deb
Hi,
On 10-09-16 00:48, Matthias Klose wrote:
> - fpc not available on powerpc anymore (may have changed recently)
For whatever it is worth, this was finally fixed this week. It is
missing on mips*, ppc64el and s390x though, while at least some form of
MIPS is supported upstream.
Paul
signatu
r's call I didn't see any toolchain support for the powerpc
architecture. For the mips* architectures we apparently have five or more
active toolchain maintainers. I very much doubt that view. From my point of
view these architecture would be perfect candidates for partial architectures,
an
Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth"
* Package name: hamradio-maintguide
Version : 0.1
Upstream Author : Iain R. Learmonth
* License : BSD-2-clause maybe
Programming Lang: Sphinx
Description : Debian Hamradio Maintainers Guide
[crossposting to -devel and -perl; M-F-T set to -devel]
There's a Perl transition (#796345) expected in the next couple of
months: Perl 5.22 packages have been in experimental since June, and
the list of blockers is getting lower. The worst blocker is currently
libapache2-mod-perl2, which needs up
Quoting Steve Langasek (2015-08-13 03:38:00)
> - if using d-shlibs (which... don't. thanks), you need to pass a
>--v5 option to it in debian/rules.
Not sure what is meant by that parenthesis. If d-shlibs is somehow an
antipattern then please clarify¹.
- Jonas
¹ I am genuinely puzzled -
Steve Langasek (2015-08-12):
> On Thu, Aug 13, 2015 at 03:14:18AM +0200, Cyril Brulebois wrote:
> > Thanks! Does the hazardous sed call touching debian/rules now account
> > for the dh_makeshlibs call(s) that might have been missed previously?
>
> I don't know about dh_makeshlibs calls specifical
local
> > machine... or upload a source package to the Debian archive without
> > building/testing/including binaries), but hopefully it's a useful
> > starting point for maintainers (or NMUers) who need to update their
> > packages for this ABI change.
> Thanks! Does
uding binaries), but hopefully it's a useful
> starting point for maintainers (or NMUers) who need to update their
> packages for this ABI change.
Thanks! Does the hazardous sed call touching debian/rules now account
for the dh_makeshlibs call(s) that might have been missed previously?
Ubuntu... or try to write
transition files to the Ubuntu instance of the release team transition
tracker, as checked out on my local machine... or upload a source package
to the Debian archive without building/testing/including binaries), but
hopefully it's a useful starting point for maintai
, etc.
Description : Guide for Debian Maintainers
This is the accompanying document of the debmake package in sid. This
document provides more practical packaging cases done in the modern
packaging style with the debmake command. As a result, unlike the old
maint-guide package, there are
Hi,
A lot has been happening recently in the Debian Hamradio Maintainers team and
these bits announce some of the things we've been working on.
Contents
1. Debian Hamradio Pure Blend Update
2. oss-removal Release Goal
3. Update on notable packages
1. Debian Hamradio Pure
ian?! :-P
>
> You tell us!
>
> I assume you're related to the recent reddit thread? If so, hi! Welcome!
> If not, also hi! Welcome!
>
haha! Thanks!!! You're very kind...^_^
No, I don't know about this thread on reddit, have you a link to it?! I
would like
1 - 100 of 948 matches
Mail list logo
