Am 7. Mai 2025 22:50:17 MESZ schrieb Vincent Lefevre :
>> > Yes, but then, shouldn't the severity be raised (as without
>> > a fix, they will no longer work in Trixie)?
>>
>> Trixie still ships the sysv-generator and we are pretty much in freeze right
>> now.
>>
>> So while I can't speak for Luca
On 2025-05-07 17:45:51 +0200, Michael Biebl wrote:
> Am 07.05.25 um 15:28 schrieb Vincent Lefevre:
> > On 2025-05-07 12:37:35 +0200, Chris Hofstaedtler wrote:
> > > * Vincent Lefevre [250507 11:06]:
> > > > I can see in journalctl output:
> > > >
> > > > May 07 10:25:13 qaa systemd-sysv-generator
On 2025-05-07 15:03:40 +, Holger Levsen wrote:
> On Wed, May 07, 2025 at 03:28:42PM +0200, Vincent Lefevre wrote:
> > Yes, but then, shouldn't the severity be raised (as without
> > a fix, they will no longer work in Trixie)?
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian
On May 07, Santiago Vila wrote:
Given that there are still 148 open bugs, I would hope systemd maintainers
consider not breaking the automatically generated units at this point
in the release cycle and do that after the release of trixie instead.
Of course! It is clearly too late for this chan
Am 07.05.25 um 15:28 schrieb Vincent Lefevre:
On 2025-05-07 12:37:35 +0200, Chris Hofstaedtler wrote:
* Vincent Lefevre [250507 11:06]:
I can see in journalctl output:
May 07 10:25:13 qaa systemd-sysv-generator[1476564]: SysV service
'/etc/init.d/dictd' lacks a native systemd unit file, auto
On Wed, May 07, 2025 at 03:28:42PM +0200, Vincent Lefevre wrote:
> Yes, but then, shouldn't the severity be raised (as without
> a fix, they will no longer work in Trixie)?
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian.org;tag=missing-systemd-service
says they are already at pri
El 7/5/25 a las 15:35, Santiago Vila escribió:
If the transitional unit stops working in trixie, does this mean
that I should better make an upload for bookworm-proposed-updates
and tell the user that they should enable it before upgrading
to trixie, so that the upgrade bookworm -> trixie does no
El 7/5/25 a las 10:48, Vincent Lefevre escribió:
What's the status of such packages?
For completeness, they are tracked using this usertag:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=bl...@debian.org;tag=missing-systemd-service
Given that there are still 148 open bugs, I would hope s
El 7/5/25 a las 12:37, Chris Hofstaedtler escribió:
They have open bugs that need fixing.
For example:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039171
Hi. While we are at it, I'd like to have some guidance on a package
for which I received one of such bugs. Asked the question here
bu
On 2025-05-07 12:37:35 +0200, Chris Hofstaedtler wrote:
> * Vincent Lefevre [250507 11:06]:
> > I can see in journalctl output:
> >
> > May 07 10:25:13 qaa systemd-sysv-generator[1476564]: SysV service
> > '/etc/init.d/dictd' lacks a native systemd unit file, automatically
> > generating a unit
* Vincent Lefevre [250507 11:06]:
I can see in journalctl output:
May 07 10:25:13 qaa systemd-sysv-generator[1476564]: SysV service
'/etc/init.d/dictd' lacks a native systemd unit file, automatically generating
a unit file for compatibility.
May 07 10:25:13 qaa systemd-sysv-generator[1476564]
On Sun, Apr 28, 2024 at 02:28:30PM +0200, Paul Gevers wrote:
> > Can you please look at libproxy<->glib-networking? libproxy excuses show
> > glib-networking tests failing, but they are working in sid.
>
> And that's not missing a versioned Depends and/or Breaks? I.e. this is a
> test only failure
Hi,
On 27-04-2024 7:52 p.m., Andrey Rakhmatullin wrote:
Can you please look at libproxy<->glib-networking? libproxy excuses show
glib-networking tests failing, but they are working in sid.
And that's not missing a versioned Depends and/or Breaks? I.e. this is a
test only failure?
Paul
Ope
On Wed, Apr 24, 2024 at 07:38:42PM +0200, Paul Gevers wrote:
> Hi,
>
> On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
> > What to do with autopkgtests that fail in testing because of problems with
> > packages in testing that are fixed in unstable, e.g. the autopkgtest for
> > speech-dispatch
Hi,
On 24-04-2024 7:42 p.m., Jérémy Lal wrote:
Inform the Release Team and we can either schedule the combination
manually, add a hint or both.
Isn't it processed automatically ? What needs manual intervention and
what doesn't ?
Well, the migration software *tries* to figure out com
Hi,
On 24-04-2024 7:38 p.m., Paul Gevers wrote:
On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
What to do with autopkgtests that fail in testing because of problems
with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
Inform the Rel
Le mer. 24 avr. 2024 à 19:39, Paul Gevers a écrit :
> Hi,
>
> On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
> > What to do with autopkgtests that fail in testing because of problems
> with
> > packages in testing that are fixed in unstable, e.g. the autopkgtest for
> > speech-dispatcher/0.1
Hi,
On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
What to do with autopkgtests that fail in testing because of problems with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
Inform the Release Team and we can either schedule the combi
On Wed, Apr 24, 2024 at 08:51:48AM +0200, Sebastian Ramacher wrote:
> If you wonder how you are able to help with the migration, here are
> some things to do:
> * Fix FTBFS bugs
> * Check the status of autopkgtests [1] and report or fix any issues
> related to failing tests.
> * Check if source-o
Hi,
dpkg and gcc with t64 enabled migrated to trixie last night. The other
packages will slowly migrate as we fix the remaining blockers
(autopkgtest regressions, FTBFS bugs, etc). Be aware that temporary
removals from trixie may occur to get packages (especially key packages)
unstuck as we work t
Hi Andreas,
please stop reopening the time_t bugs where transitions are staged in
experimental. When we eventually start those transitions, they do not
need to change the package name again as they will enter unstable with a
new SONAME and built with the 64 bit time_t ABI.
Cheers
--
Sebastian Ra
Lists updated to omit packages not in testing:
On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include pack
On 18.04.24 21:22, Sebastian Ramacher wrote:
Hi,
as the progress on the t64 transition is slowing down, I want to give an
overview of some of the remaining blockers that we need to tackle to get
it unstuck. I tried to identify some clusters of issues, but there might
be other classes of issues.
All missing bugs about wrong deps are now filed.
--
WBR, wRAR
signature.asc
Description: PGP signature
Hi
thanks for checking all the packages and filing bugs!
On 2024-04-20 00:43:30 +0500, Andrey Rakhmatullin wrote:
> On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> > Let's start with the first category. Those are packages that could be
> > binNMUed, but there are issues that
Hi Andreas
On 2024-04-19 10:49:15 +0200, Andreas Tille wrote:
> I've spotted these Debian Med packages.
>
> > gentle
gentle required a rebuild for wxwidgets3.2 on mips64el. Done
> > jellyfish
The t64 changes were reverted. crac needs to rebuilt for this change so
that libjellyfish-2.0-2t64 can
On 2024-04-19 10:34:45 +0200, Simon Josefsson wrote:
> Sebastian Ramacher writes:
>
> > Hi,
> >
> > as the progress on the t64 transition is slowing down, I want to give an
> > overview of some of the remaining blockers that we need to tackle to get
> > it unstuck. I tried to identify some cluste
On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
> * are BD-Uninstallabe,
> * FTBFS b
Hi Sebastian,
Andreas Tille, on 2024-04-19:
> I've spotted these Debian Med packages.
[…]
> Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher:
[…]
> > jellyfish
> > quorum
[…]
> No idea how we can help here. Please let us know if we can do
> something.
About these two packages,
Hi Sebastian,
thank you for your work on t64 transition.
Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher:
I've spotted these Debian Med packages.
> gentle
> jellyfish
> quorum
> sbmltoolbox
No idea how we can help here. Please let us know if we can do
something.
> anfo
W
Hello,
On Thu, 2024-04-18 at 21:22 +0200, Sebastian Ramacher wrote:
> Finally, packages that need rebuilds but currently have open FTBFS (RC +
> ftbfs tag) bugs:
> (...)
> virtualjaguar
I already have a tentative patch and will fix the package within the next
days. I am also preparing to fix two
Sebastian Ramacher writes:
> Hi,
>
> as the progress on the t64 transition is slowing down, I want to give an
> overview of some of the remaining blockers that we need to tackle to get
> it unstuck. I tried to identify some clusters of issues, but there might
> be other classes of issues.
Thanks
On 2024-04-19 06:02:03 +0200, Andreas Metzler wrote:
> On 2024-04-18 Sebastian Ramacher wrote:
> [...]
> > Let's start with the first category. Those are packages that could be
> > binNMUed, but there are issues that make those rebuilds not have the
> > desired effect. This list include packages t
On 2024-04-18 Sebastian Ramacher wrote:
[...]
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
> * are BD-Uninstallabe,
> * FTBFS but with out ftbfs-tag
Peter wrote:
>
>I've just noticed that the weekly live builds (both the free ones [0]
>and the unofficial non-free ones [1]) have not been updated since August
>9, 2021. Is this on purpose or did some machinery get stuck?
I disabled the testing live image builds after the bullseye release,
and I
Hi Ondřej,
thanks for chiming in.
Ondřej Surý:
>
> I still don’t understand why everybody suddenly thinks PHP is special
> in any way. The packages will be treated same as any other Debian
> package - the important security fixes will be backported.
I am not sure who you are addressing (I may h
I still don’t understand why everybody suddenly thinks PHP is special
in any way. The packages will be treated same as any other Debian
package - the important security fixes will be backported.
Ondrej
> On 8 Feb 2019, at 22:06, Jochen Spieker wrote:
>
> Hi,
>
> I originally sent this to debi
On 2018-06-05 23:15, Simon McVittie wrote:
> NetworkManager supports PPPOE (e.g. ADSL), and cellular modems (3G, etc.)
> via ModemManager. It doesn't support the analogue dial-up modems that
> were popular 10-20 years ago. I don't think the major NM alternatives
> (wicd, ConnMan etc.) support those
On Tue, 05 Jun 2018 at 21:46:37 +0200, Sebastian Andrzej Siewior wrote:
> wvstreams has a RC bug due to the openssl transition. There seems not to
> be any upstream activity, the last commit on github was from 2011. It
> has one reverse dependency which is wvdial.
> wvdial itself saw its last uploa
I'm forwarding this to d-devel@ to reach a broader audience since my
initial email received no feedback.
Hi,
wvstreams has a RC bug due to the openssl transition. There seems not to
be any upstream activity, the last commit on github was from 2011. It
has one reverse dependency which is wvdial.
w
On Fri, 23 Feb 2018, Geert Stappers wrote:
> On Fri, Feb 23, 2018 at 09:44:16PM +0100, Alexander Wirt wrote:
> > On Fri, 23 Feb 2018, Geert Stappers wrote:
> > > El 23/02/18 a las 20:51, Laura Arjona Reina escribió:
> > > > El 23/02/18 a las 19:42, Geert Stappers escribió:
> > > > > I went to Debi
On Fri, Feb 23, 2018 at 09:44:16PM +0100, Alexander Wirt wrote:
> On Fri, 23 Feb 2018, Geert Stappers wrote:
> > El 23/02/18 a las 20:51, Laura Arjona Reina escribió:
> > > El 23/02/18 a las 19:42, Geert Stappers escribió:
> > > > I went to Debian wiki, searched for 'SSO'
> > > > and got https://wi
On Fri, 23 Feb 2018, Geert Stappers wrote:
> On Fri, Feb 23, 2018 at 08:53:59PM +0100, Laura Arjona Reina wrote:
> > El 23/02/18 a las 20:51, Laura Arjona Reina escribió:
> > > El 23/02/18 a las 19:42, Geert Stappers escribió:
> > >
> > >>
> > >> I went to Debian wiki, searched for 'SSO'
> > >> a
On Fri, Feb 23, 2018 at 08:53:59PM +0100, Laura Arjona Reina wrote:
> El 23/02/18 a las 20:51, Laura Arjona Reina escribió:
> > El 23/02/18 a las 19:42, Geert Stappers escribió:
> >
> >>
> >> I went to Debian wiki, searched for 'SSO'
> >> and got https://wiki.debian.org/Salsa/SSO
> >>
> >> Would t
El 23/02/18 a las 20:51, Laura Arjona Reina escribió:
>
>
> El 23/02/18 a las 19:42, Geert Stappers escribió:
>
>>
>> I went to Debian wiki, searched for 'SSO'
>> and got https://wiki.debian.org/Salsa/SSO
>>
>> Would that be the proper place to track status of Debian Single Sign On?
>>
>
> Th
El 23/02/18 a las 19:42, Geert Stappers escribió:
>
> I went to Debian wiki, searched for 'SSO'
> and got https://wiki.debian.org/Salsa/SSO
>
> Would that be the proper place to track status of Debian Single Sign On?
>
The page is https://wiki.debian.org/DebianSingleSignOn
I've just redirect
On Fri, 23 Feb 2018, Geert Stappers wrote:
> On Fri, Feb 23, 2018 at 07:32:24PM +0100, Alexander Wirt wrote:
> > On Fri, 23 Feb 2018, Geert Stappers wrote:
> > > On Fri, Feb 23, 2018 at 06:54:29PM +0100, Alexander Wirt wrote:
> > > > On Fri, 23 Feb 2018, Enrico Zini wrote:
> > > > > Please do not
On 12/08/2016 19:50, Samuel Thibault wrote:
Felipe Sateler, on Fri 12 Aug 2016 17:44:20 +, wrote:
localed by itself does little more than updating /etc/default/keyboard et
al[1] (it can set XKBMODEL, XKBVARIANT, XKBLAYOUT and XKBOPTIONS in that
file). It then tries to invoke systemd-vconsole
Hello,
Felipe Sateler, on Fri 12 Aug 2016 17:44:20 +, wrote:
> localed by itself does little more than updating /etc/default/keyboard et
> al[1] (it can set XKBMODEL, XKBVARIANT, XKBLAYOUT and XKBOPTIONS in that
> file). It then tries to invoke systemd-vconsole, which is the service
> that
On Wed, 10 Aug 2016 23:51:31 +0200, Samuel Thibault wrote:
> Hello,
>
> Cesare Leonardi, on Sun 31 Jul 2016 16:22:54 +0200, wrote:
>> Console-data package was last updated in 2014, was reported obsolete
>> for a long time and user reporting bug to it are sollecited to migrate
>> to console-setup.
Hello,
Cesare Leonardi, on Sun 31 Jul 2016 16:22:54 +0200, wrote:
> Console-data package was last updated in 2014, was reported obsolete for a
> long time and user reporting bug to it are sollecited to migrate to
> console-setup. For example see the preistoric bug #626680 (still valid). And
> upst
On 31/07/2016 15:22, Cesare Leonardi wrote:
> Hello.
> The freeze date is about three months away and i'd like to know if
> there are any plans about these packages before then.
>
> The main problem is that currently systemd comes with a partially
> broken localectl, well explained here:
> https:/
* Simon Kainz [2016-07-14 15:03:56 +0200]:
> Hello,
>
> in the QA BoF at DC16 fedmsg was briefly mentioned, and I only found
> [0], but could not find out what happened to the project. Has somebody
> some more information about this?
>
> [0] https://lists.debian.org/debian-devel/2013/04/msg0076
On Sep 23 2015, Aurelien Jarno wrote:
> On 2015-09-23 14:21, Didier 'OdyX' Raboud wrote:
>> Hi Nikolaus,
>>
>> Le jeudi, 17 septembre 2015, 09.27:56 Nikolaus Rath a écrit :
>> > On Sep 17 2015, Didier 'OdyX' Raboud wrote:
>> > > Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
>> >
On 2015-09-23 14:21, Didier 'OdyX' Raboud wrote:
> Hi Nikolaus,
>
> Le jeudi, 17 septembre 2015, 09.27:56 Nikolaus Rath a écrit :
> > On Sep 17 2015, Didier 'OdyX' Raboud wrote:
> > > Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
> > >> I don't know about formal LSB compatibility,
On Sep 23 2015, Didier 'OdyX' Raboud wrote:
> Hi Nikolaus,
>
> Le jeudi, 17 septembre 2015, 09.27:56 Nikolaus Rath a écrit :
>> On Sep 17 2015, Didier 'OdyX' Raboud wrote:
>> > Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
>> >> I don't know about formal LSB compatibility, but the
Le jeudi, 17 septembre 2015, 23.00:51 Michael Biebl a écrit :
> Am 17.09.2015 um 14:56 schrieb Didier 'OdyX' Raboud:
> > After the discussion [0] about these changes back in July (on both
> > debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826
> > to
> > unstable, building no LSB com
Hi Nikolaus,
Le jeudi, 17 septembre 2015, 09.27:56 Nikolaus Rath a écrit :
> On Sep 17 2015, Didier 'OdyX' Raboud wrote:
> > Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
> >> I don't know about formal LSB compatibility, but there are several
> >> proprietary applications that req
m...@linux.it (Marco d'Itri) writes:
> Is there any point in (formally?) maintaining LSB compatibility? Is
> there any proprietary application that does actually benefit from it in
> the real world?
LSB seems pretty dead. I'm dubious there's much point in investing effort
in this.
--
Russ All
Am 17.09.2015 um 14:56 schrieb Didier 'OdyX' Raboud:
> After the discussion [0] about these changes back in July (on both
> debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826 to
> unstable, building no LSB compatibility packages anymore (besides lsb-
> release and lsb-base). As fa
Hi Didier,
(Please honor the Mail-Followup-To or Mail-Copies-To header, thanks!)
On Sep 17 2015, Didier 'OdyX' Raboud wrote:
> Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
>> I don't know about formal LSB compatibility, but there are several
>> proprietary applications that requ
Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
> I don't know about formal LSB compatibility, but there are several
> proprietary applications that require nothing but the
> /{lib,lib64}/ld-lsb.so* symlinks to work properly under Debian. So it
> would be great if they could be preser
On Sep 17 2015, m...@linux.it (Marco d'Itri) wrote:
> On Sep 17, Didier 'OdyX' Raboud wrote:
>
>> This change landed in stretch on September 14. and is de facto the
>> "outright giving up" of LSB support for Debian, from stretch onwards. As
>
> Is there any point in (formally?) maintaining LSB c
On Sep 17, Didier 'OdyX' Raboud wrote:
> This change landed in stretch on September 14. and is de facto the
> "outright giving up" of LSB support for Debian, from stretch onwards. As
Is there any point in (formally?) maintaining LSB compatibility?
Is there any proprietary application that does
On 30/06/15 07:34, Niels Thykier wrote:
> On 2015-06-30 07:14, Paul Wise wrote:
>> A lot of derivatives use reprepro, do you know how that will handle
>> ddebs? Perhaps it should get a default filter to put ddebs into
>> separate archive components? main/dbgsym etc.
>
> No, I do not concretely kno
On 2015-06-30 07:20, Tomas Pospisek wrote:
> May I suggest you add:
>
> What is it?
> ===
>
> * ddeb's are Debian packages with the extenstion .ddeb that
> contain debugging symbols and are built implicitly.
> - A package foo_1.23.deb will receive a corresponding
> foo_1.23-dbgsym
On 2015-06-30 07:14, Paul Wise wrote:
> On Tue, Jun 30, 2015 at 12:17 AM, Niels Thykier wrote:
>
>> * [Derivatives] Please consider upgrading your infrastructure /
>>tooling if/where needed.
>
> A lot of derivatives use reprepro, do you know how that will handle
> ddebs? Perhaps it should ge
On 2015-06-29 22:06, Vincent Bernat wrote:
> ❦ 29 juin 2015 18:17 +0200, Niels Thykier :
>
>> * Only known blocker is missing archive/dak support.
>
> Is any help needed here?
>
It has been a while since I synchronised with the FTP masters (CC'ed),
so things might have changed. From memory:
On 2015-06-29 22:00, Jakub Wilk wrote:
> * Niels Thykier , 2015-06-29, 18:17:
>> * debhelper in unstable can now build ddebs - disabled by default.
>
> Thanks!
>
>> - Test with env DH_BUILD_DDEBS=1, but please don't upload ddebs to any
>> Debian archive.
>
> It almost works. The *-dbgsym_*.deb p
May I suggest you add:
What is it?
===
* ddeb's are Debian packages with the extenstion .ddeb that
contain debugging symbols and are built implicitly.
- A package foo_1.23.deb will receive a corresponding
foo_1.23-dbgsym.ddeb package.
- ddebs are built automatically by dh_strip.
On Tue, Jun 30, 2015 at 12:17 AM, Niels Thykier wrote:
> * [Derivatives] Please consider upgrading your infrastructure /
>tooling if/where needed.
A lot of derivatives use reprepro, do you know how that will handle
ddebs? Perhaps it should get a default filter to put ddebs into
separate arch
❦ 29 juin 2015 18:17 +0200, Niels Thykier :
> * Only known blocker is missing archive/dak support.
Is any help needed here?
--
Keep it right when you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)
signature.asc
Description: PGP signature
* Niels Thykier , 2015-06-29, 18:17:
* debhelper in unstable can now build ddebs - disabled by default.
Thanks!
- Test with env DH_BUILD_DDEBS=1, but please don't upload ddebs to any
Debian archive.
It almost works. The *-dbgsym_*.deb packages were built, but for
whatever reason the were n
Keivan Motavalli wrote:
> Hi, debian does not support the, in my opinion, highly useful
> "sandbox" tool from selinux package policycoreutils.
>
> It allows, for example, to run a sandboxed instance of a web-browser
> with vulnerable plugins with a single line script.
>
> selinux support is curre
On 2014-02-20 18:21, Steve Langasek wrote:
> On Thu, Feb 20, 2014 at 12:31:28PM +, Colin Watson wrote:
>> On Wed, Feb 19, 2014 at 02:29:45PM -0800, Steve Langasek wrote:
>>> Ok. The statistics still seem awfully low to me; but I guess
>>> http://people.debian.org/~cjwatson/dhstats.png shows th
On Thu, Feb 20, 2014 at 12:31:28PM +, Colin Watson wrote:
> On Wed, Feb 19, 2014 at 02:29:45PM -0800, Steve Langasek wrote:
> > Ok. The statistics still seem awfully low to me; but I guess
> > http://people.debian.org/~cjwatson/dhstats.png shows there hasn't actually
> > been a huge uptick in
On Wed, Feb 19, 2014 at 02:29:45PM -0800, Steve Langasek wrote:
> Ok. The statistics still seem awfully low to me; but I guess
> http://people.debian.org/~cjwatson/dhstats.png shows there hasn't actually
> been a huge uptick in dh(1) adoption over the past year, as a percentage of
> all packages.
On Wed, Feb 19, 2014 at 09:28:48PM +, Roger Leigh wrote:
> Current unstable dpkg building openldap:
> > Starting test048-syncrepl-multiproxy for mdb...
> running defines.sh
> Starting master slapd on TCP/IP port 9011...
> Using ldapsearch to check that master slapd is running...
> Using ld
On Wed, Feb 19, 2014 at 01:02:55PM -0800, Steve Langasek wrote:
> On Wed, Feb 19, 2014 at 01:58:48PM +0100, Jakub Wilk wrote:
> > Thanks for doing the rebuilds!
>
> > * Roger Leigh , 2014-02-18, 22:58:
> > >┌┬┬───┐
> > >│ current │ buildarch │ count │
> > >├
On Wed, Feb 19, 2014 at 01:58:48PM +0100, Jakub Wilk wrote:
> Thanks for doing the rebuilds!
> * Roger Leigh , 2014-02-18, 22:58:
> >┌┬┬───┐
> >│ current │ buildarch │ count │
> >├┼┼───┤
> >│ attempted │ attempted │ 317 │
> >│ attempt
On Wed, Feb 19, 2014 at 01:58:48PM +0100, Jakub Wilk wrote:
> Thanks for doing the rebuilds!
>
> * Roger Leigh , 2014-02-18, 22:58:
> >┌┬┬───┐
> >│ current │ buildarch │ count │
> >├┼┼───┤
> >│ attempted │ attempted │ 317 │
> >│ attem
On Tue, Feb 18, 2014 at 10:58:50PM +, Roger Leigh wrote:
> I hope the above is useful for measuring progress on this front. Do
> we have any plans for enforcing build-arch for jessie at this point?
> If we haven't already, stronger warnings when running dpkg-buildpackage
> and stronger lintian
Adam Borowski writes:
> On Thu, Sep 19, 2013 at 11:31:32AM -0700, Russ Allbery wrote:
>> I think Adam's point is that there's a one-to-one correspondance
>> between a 3.0 (quilt) package and a 3.0 (git) package that consists
>> solely of an import of the most recent upstream source plus one commi
Russ Allbery writes:
> Adam Borowski writes:
>> You can trim the history at any commits you want.
> Trimming the history of commits doesn't help. In order to have
> something that's equivalent from a license review standpoint, you have
> to rebase all of the commits into something akin to the
On Thu, Sep 19, 2013 at 11:31:32AM -0700, Russ Allbery wrote:
> Ben Hutchings writes:
>
> > Of course unreachable objects should be pruned from a 3.0 (git) package.
> > But I believe the FTP team's concerns are about *reachable* objects that
> > may be copyright violations. It is hard enough to
Ben Hutchings writes:
> Of course unreachable objects should be pruned from a 3.0 (git) package.
> But I believe the FTP team's concerns are about *reachable* objects that
> may be copyright violations. It is hard enough to check this for one
> version.
I think Adam's point is that there's a on
On Thu, Sep 19, 2013 at 04:25:06PM +0200, Adam Borowski wrote:
[...]
> I don't understand the arguments against 3.0 (git). For every 3.0 (quilt)
> package, you can produce a 3.0 (git) with exactly the same data (but not
> metadata[1]) bits.
>
> It is claimed that it can smuggle some not visible
On Wed, 18 Sep 2013, Ian Jackson wrote:
> I don't think removing .pc and debian/patches will DTRT because
> dpkg-source -x will produce a directory containing them. dgit's idea
> of "the source tree from the source package" is "whatever dpkg-source
> -x produces".
You could decide that the canoni
On Wed, Sep 18, 2013 at 05:42:17PM +0100, Ian Jackson wrote:
> Adam Borowski writes
> > Here's one way:
> > rm -rf .pc debian/patches
> > echo single-debian-patch >>debian/source/options
> >
> > The rm needs to be repeated, either in the "clean" target or perhaps by
> > dgit.
>
> I don't think re
Ian Jackson wrote:
> That it doesn't browse well is indeed annoying. On the server the
> dgit suite branch ref names aren't in refs/heads/, which is needed to
> stop git pushing to them by default. But that makes gitweb not show
> them either. I'm open to suggestions for how to improve this.
>
Ian Jackson writes:
> Single-patch "3.0 (quilt)" is still IMO insane. The droppings in .pc
> and debian/patches (which require workarounds in dgit) also mean (for
> example) that a debdiff of a one-line change contains a giant pile of
> poo.
I don't understand what you mean by this. I do debdi
Ben Hutchings writes ("Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)"):
> Example from sgt-puzzles:
>
> override_dh_auto_clean:
> ! [ -f Makefile ] || $(MAKE) clean
> $(MAKE) -f Makefile.doc clean
>
Ian Jackson writes:
> If your source package contains the files, and your git tree does too,
> then you will find that debian/rules clean generates a dirty git tree.
> How do you deal with this problem at the moment ?
Generally by not running debian/rules clean in my source repository or, if
so,
Adam Borowski writes ("Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)"):
> On Tue, Sep 17, 2013 at 07:02:04PM +0100, Ian Jackson wrote:
> > Or you could simply ignore the format `3.0 (quilt)' thing entirely and
> > allow it to automatically
Ian Jackson writes:
> Russ Allbery writes:
>> This is common. Usually it's because upstream ships generated files in
>> the upstream tarball as well as source files. As part of building the
>> Debian package from source, one wants to remove all generated files and
>> recreate them. Deleting th
Cyril Brulebois writes ("Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)"):
> Charles Plessy (2013-09-18):
> > for a small native package that I prepared, I would like to indicate dgit's
> > repository as VCS in its source control file (Vcs-B
Julien Cristau writes ("Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)"):
> On Wed, Sep 18, 2013 at 14:16:32 +0100, Ian Jackson wrote:
> > Julien Cristau writes ("Re: Status of dgit (good for NMUs and
> > fast-forwarding Debian branches)&qu
On Wed, Sep 18, 2013 at 14:16:32 +0100, Ian Jackson wrote:
> Julien Cristau writes ("Re: Status of dgit (good for NMUs and fast-forwarding
> Debian branches)"):
> > No, I mean the upstream tarball contains autotools-generated files that
> > debian/rules delete
On Wed, 2013-09-18 at 14:49 +0100, Ian Jackson wrote:
> Ben Hutchings writes ("Re: Status of dgit (good for NMUs and fast-forwarding
> Debian branches)"):
> > Example from sgt-puzzles:
> >
> > override_dh_auto_clean:
> > ! [ -f Makefile ] || $(MAK
Ben Hutchings writes ("Re: Status of dgit (good for NMUs and fast-forwarding
Debian branches)"):
> Example from sgt-puzzles:
>
> override_dh_auto_clean:
> ! [ -f Makefile ] || $(MAKE) clean
> $(MAKE) -f Makefile.doc clean
>
1 - 100 of 592 matches
Mail list logo
