Santiago Vila writes:
> Package: src:pcb
> Version: 1:4.3.0-3
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to
> build:
Upstream for pcb is mostly inactive, and many users have moved to
pcb-rnd, which started as a for
Helmut Grohne writes:
> Source: openrocket
> Severity: serious
> Justification: grab attention of maintainer
> User: helm...@debian.org
> Usertags: sidremove
>
> Dear maintainer,
>
> I suggest removing openrocket from Debian
I agree.
Upstream now offers for download a 'fat' jar file that can be
Adrian Bunk writes:
> librnd4t64 provides librnd4 only on the architectures
> where no ABI change was done for 64bit time_t.
I think this is a consequence of trying to ensure librnd4 is at version
4.2.0 or later, rather than just letting ${shlibs:Depends} do the right
thing.
Bdale
signature.
Package: librnd
Severity: serious
Version: 4.2.0-1
There appears to be a bug in this version of librnd that prevents successful
rendering with the default gtk 4 hid. In the short term, users can work
around the problem by installing librnd4-hid-lesstif and invoking the various
ringdove tools wi
Gianfranco Costamagna writes:
> yes, but the library was renamed in librnd4t64, so either you need to
> depend on the new one, or drop it, to let the auto decrufter finish
> the time64_t transition and decruft it.
Ah, thank you, that's a useful observation. Since the relevant version
hasn't mad
Gianfranco Costamagna writes:
> Hello, I found that librnd4 is correctly evaluated from shlibs:Depends
> in the core library and then it can be dropped also on core
> reverse-dependencies.
The point of the dependency is to require version 4.1.0 or later, since
that's the librnd version that adde
This appears to be another manifestation of the incompatibility with
python3.12 reported in #1059647. I'm not going to mark it as a
duplicate in the BTS since the process of getting there is so different,
but I believe the fix will be the same. Upstream has reworked the build
process to allow use
tags 1059647 +upstream
thanks
Upstream reports in https://github.com/scikit-fmm/scikit-fmm/issues/78
that this issue is fixed on a development branch, and will be merged and
released as soon as a test suite issue gets resolved.
Bdale
signature.asc
Description: PGP signature
tags 1066248 +pending
tags 1049315 +pending
thanks
Last night I successfully completed a test build of librnd from upstream
svn trunk that resolves all open Debian bugs. The next upstream release
is still expected on 10 April, and I plan to update the Debian librnd
package immediately after that
Peter Michael Green writes:
> The functions in question are defined in
> src/librnd/plugins/hid_lesstif/dialogs.c
> and used in src/librnd/plugins/hid_lesstif/main.c
Correct. Upstream has fixed this and will have a new release on 10
April that I'm waiting for rather than patching the current D
tags 1059647 +help
thanks
Graham Inggs writes:
> Source: scikit-fmm
> Version: 2022.08.15-4
> Severity: serious
> User: debian-pyt...@lists.debian.org
> Usertags: python3.12
>
> Hi Maintainer
>
> scikit-fmm's autopkgtests fail with Python 3.12 [1]. I've copied what
> I hope is the relevant part
You have my permission.
Bdale
On December 14, 2023 11:54:24 AM MST, Alexandre Detiste
wrote:
>Hi,
>
>I ll try to fix this one if you permit.
>
>
>Greetings
tony mancill writes:
> So this is very possibly a bug in libreoffice-writer-nogui.
Sure seems like it. My guess would be that what files go in what
libreoffice binary packages got refactored somehow? Not sure what the
point of the nogui package is if it can't be used here any more.
[shrug]
I
Lucas Nussbaum writes:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
I am unable to reproduce this problem building in a fresh, minimal sid
chroot environment. Is this a repeatable failure? If so, any thoughts
on what might cause it to fail in your build e
Lucas Nussbaum writes:
> Source: camv-rnd
> Version: 1.1.1-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230216 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
Sadl
Package: sch-rnd
Version: 0.9.3-1
Severity: serious
Upstream was happy for me to package sch-rnd for Debian unstable, but
would prefer we not include it in a stable release until he makes a
stable upstream 1.0 release.
Bdale
signature.asc
Description: PGP signature
Lucas Nussbaum writes:
> Source: pcb-rnd
> Version: 3.0.5-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221023 ftbfs-bookworm
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
Thanks for th
Moritz Mühlenhoff writes:
> If lepton-eda is a sufficient drop-in replacement for existing geda-gaf
> users, lepton could provide a geda-gaf transition package for the bookworm
> release? I can file a bug against lepton-eda when geda-gaf has been
> removed.
Yes, we could certainly do that.
Bdal
Moritz Muehlenhoff writes:
> Source: geda-gaf
> Version: 1:1.8.2-11
> Severity: serious
>
> Your package came up as a candidate for removal from Debian:
For the record, I've previously indicated that I consider lepton-eda a
complete replacement for geda-gaf in Debian. It was forked some years
a
Paul Gevers writes:
> Your package fails to build on s390x where it build successfully in
> the past. I've X-Debbugs-CC-ed the s390x porters to help you
> understand why only this architecture is affected.
It's hard to imagine anyone actually trying to use lepton-eda on s390x.
If the porting tea
severity 1002252 important
thanks
Lucas Nussbaum writes:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
It looks like noise from the latest librnd version is causing a pcb-rnd
test failure. There is no operational bug in either the library or the
applicatio
Andreas Beckmann writes:
> I'm not sure whether it would be helpful, but a (versioned?)
> Provides: librnd-dev (= ${binary:Version})
> could ease upgrading from librnd-dev to librnd3-dev.
Yes, that makes sense.
> BTW, why has the -dev package been renamed from librnd-dev to librnd3-dev?
> I
Andreas Beckmann writes:
> Package: openrocket
> Version: 15.03.6
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package is no longer
> installable in sid:
>
> The following packages have unmet dependencies:
>
severity 977595 serious
thanks
Vanessa Dannenberg writes:
Hi Vanessa!
> Package: lepton-eda
> Version: 1.9.13-1
> Severity: grave
>
> [ This is a fresh install of Bullseye/testing, from a net-install
> image fetched just today]
I couldn't duplicate your problem on my "unstable" development sys
Paul Gevers writes:
> Your package Depends on openjdk-8, which isn't supposed to be used in
> testing since beginning 2019.
FYI, this dependency will remain until/unless upstream makes a new
release, and is still present in the version in unstable.
Bdale
signature.asc
Description: PGP signatu
Sudip Mukherjee writes:
> Control: tags 957019 + patch
> Control: tags 957019 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for atlc (versioned as 4.6.1-2.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should cancel it.
Thank you!
Bdale
signature.asc
Descripti
block 966736 by 965098
tags +wontfix
thanks
Matthias Klose writes:
> Package: src:geda-gaf
> Version: 1:1.8.2-11
> Severity: serious
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2unversioned
I've already requested removal of the geda-gaf package, so do not plan
to f
tags 949519 + help
thanks
I do not currently have the facilities or the motivation to try and
debug LDAP issues in sudo. Happy to merge a patch if someone else
figures out what's going wrong here.
Bdale
signature.asc
Description: PGP signature
Rob Browning writes:
> Bdale Garbee writes:
>
>> However, I see little chance of geda-gaf upstream working on the things
>> needed to keep it viable in Debian any time soon, and with lepton-eda in
>> my mind a complete replacement that still works with the same file
&
Rob Browning writes:
> Bdale Garbee writes:
>
>> I'm not interested in maintaining pcb any more.
>
> Does that mean geda-gaf etc? If so might it make sense for you (or
> who?) to file a removal request, i.e. ROM or similar?
Sorry, you make a good point, geda-gaf and
tags 964922 +pending
thanks
Thorsten Glaser writes:
> On Sun, 12 Jul 2020, Bdale Garbee wrote:
>
>> However, since your but report caused *me* to go read that and realize @
>> is now preferred to # for that directive, I'm updating the default
>> sudoers file for D
I'm not interested in maintaining pcb any more.
Bdale
On July 13, 2020 7:04:01 PM MDT, Rob Browning wrote:
>Bdale Garbee writes:
>
>> So... while I'm sure gEDA could be "saved" in Debian with enough
>effort,
>> I just don't see the point, and w
أحمد المحمودي writes:
> On Mon, Apr 27, 2020 at 08:48:59PM -0600, Bdale Garbee wrote:
>> As far as I'm concerned, you can feel free to remove geda-gaf from Debian.
>>
>> I'm personally quite happily living on the fork that I've packaged of
>> lepton-ed
Rob Browning writes:
> Please try to migrate soon, and at this point, to guile-3.0 if possible.
> Otherwise we might need to consider removing the package from Debian.
As far as I'm concerned, you can feel free to remove geda-gaf from Debian.
I'm personally quite happily living on the fork that
tags 949519 +needhelp
thanks
I don't have any easy way to debug LDAP issues. If someone else does
and wants to chase this down and let me know where the problem is,
that'd be great.
Bdale
signature.asc
Description: PGP signature
Jörg Mechnich writes:
>> DEB_CPPFLAGS_MAINT_APPEND := -DUNALIGNED_OK
That was originally meant to only be enabled on amd64 .. I think that
got lost in one of the packaging style updates I accepted a while back.
Just uploaded 1.10-2 hopefully making the architecture-specificity true
again.
Bdal
Hans-Christoph Steiner writes:
> this also goes the other way, where tarballs created in tar 1.30 fail to
> work in pristine-tar when tar 1.29 is installed:
Unfortunately, the nature of pristine-tar is such that it's somewhat
brittle in the face of upstream changes to tar.
I don't think it's un
tags 901952 +help
thanks
I question whether this bug is really release-critical, since the only cases
of it I've heard about so far are the two instances pointed to in this bug log
where pristine-tar is being used across distributions and versions... I've not
seen the behavior in any of my own pac
Adrian Bunk writes:
> Package: openrocket
> Version: 13.05.1
> Severity: serious
>
> openrocket was turned into an installer that downloads
> the actual softare during package installation.
>
> In this state it mustn't be in main.
Oops, you're right. Working on it now.
Bdale
signature.asc
De
tags 908553 +unreproducible
severity 908553 normal
thanks
I've been unable to reproduce this problem, and am in fact a nearly-daily
user of pcb-rnd.
If the problem is persistent for you, I'm going to need to know more about
your system config, how you're invoking pcb-rnd, etc, to be able to usef
We need to isolate which upstream commit caused the behavior change.
I've got other things to work on that are higher priority to me right
now, so help from someone more motivate to chase this down would be
appreciated.
Bdale
signature.asc
Description: PGP signature
Paul Eggert writes:
> On 05/14/2018 07:56 AM, Antonio Terceiro wrote:
>> I still need to study the > code a bit further to try to come up with a
>> better suggestion.
> Sorry, the only suggestion I can make is that you should just use the
> new GNU tar. The old one was obviously busted and it
Andreas Beckmann writes:
> during a test with piuparts I noticed your package failed to install due
> to insserv rejecting the script header.
Thanks for letting me know.
> We had a similar problem in the past ... #719755
> Looks like the fix for #870456 "enabled" this bug again.
Hrm. Right, b
Laurent Bigonville writes:
> It seems that the postinst script is exiting in the middle of the script
> if the sudo group exists bypassing all the bits added by debhelper.
Not intentional, but it looks like the only thing there is the
dh_installinit fragment setting up the rc.d actions. That wo
Adrian Bunk writes:
> Now one test is taking over 6 hours (is that completely hanging?).
I have no idea. Never seen that happen. Makes me wonder what's changed
in your kernel or toolchain since the last build?
Bdale
signature.asc
Description: PGP signature
Dima Kogan writes:
> I'm attaching two patches to fix this. Please review soon if
> possible. If I don't hear back by Dec 26, I'll NMU this. That's the
> latest possible day to meet the cutoff for stretch.
Thank you for your work on this. I see that an upload has happened.
Please push this patc
I've packaged and uploaded mdocml/mandoc, as soon as it's accepted into the
archive I'll be able to update the build process for sudo to fix this.
Bdale
Niko Tyni writes:
> On Wed, Dec 30, 2015 at 08:24:09AM +, Debian Bug Tracking System wrote:
>> > # still depends on perl5
>> > found 808233 1.0-15
>> Bug #808233 {Done: Bdale Garbee } [p10cfgd] p10cfgd: Depends
>> on virtual package "perl5" whi
Raphael Hertzog writes:
> If you don't want to take care of this update, it's not a problem, we
> will do our best with your package. Just let us know whether you would
> like to review and/or test the updated package before it gets
> released.
I would be pleased to review the updated package be
Christian Kastner writes:
> All of the RC fixes have been in unstable for a while now, so an upload
> to t-p-u could be negotiated now with the RT. If you'd like me to take
> care of that, please let me know.
Go for it. I'm likely to remain too busy to work on it much for the next
week or so.
Christian Kastner writes:
> Bdale, once such a confirmation (or another fix) is in, how would you
> like to proceed? I could help with the RT communication again
Sure. I'm willing to merge a patch and do uploads, but need to know
which path they want me to use since the sudo in unstable has div
Christian Kastner writes:
> Hi,
>
> with a patch now available for the versions in testing and in unstable,
> I believe what still needs to be done is:
>
> 1. Negotiate with RT which version they'd be willing to accept
> 2. Prepare a package including the application patch version
> 3. Uplo
"C. Scott Ananian" writes:
> FWIW, manually running update-openrocket after install seemed to work
> fine:
Thanks for your bug report, and I'm glad you were able to get it
working.
It sounds like there may have been a transient problem with the upstream
website that hosts the .jar file we downl
Chow Loong Jin writes:
> On Wed, Aug 06, 2014 at 01:09:24PM -0600, Bdale Garbee wrote:
>> Package: slic3r
>> version: 1.1.7+dfsg-1
>> Severity: serious
>>
>> On an up-to-date system running sid:
>>
>> bdale@rover:~$ slic3r
>> Running Slic3r
Package: slic3r
version: 1.1.7+dfsg-1
Severity: serious
On an up-to-date system running sid:
bdale@rover:~$ slic3r
Running Slic3r under Perl >= 5.16 is not supported nor recommended
Can't locate object method "new" via package "Slic3r::Model" at
/usr/share/perl5/Slic3r/GUI/Plater.pm line 53.
bda
Package: pithos
Version: 0.3.17-2
Severity: grave
Installing pithos on my notebook running xfce4 resulted in odd errors about
gstreamer not finding resources. A quick web search led me to this bug
report in launchpad:
https://bugs.launchpad.net/pithos/+bug/1007065
Manually installing py
Apparently python3.4 showed up since python-bcrypt was last uploaded. The
result is that trying to build fails on the python3.4 pass due to the
associated dev package not being pulled in by python3-dev.
Adding python3-all-dev to the build-deps seems to fix the problem.
I care because this impa
Kurt Roeckx writes:
> It seems that the last upload (1:1.8.2-2) killed at least 4
> buildds. This includes amd64 (brahms), armhf (hoiby),
> armel (alwyn, ancina). I understand that some of them are
> still down because of it.
That's unfortunate. What does "killed" mean here? I'd love to know
severity 724922 important
thanks
أحمد المحمودي writes:
> In that case, maybe the bug severity should be reduced ?
Sure, makes sense to me.
Bdale
pgp1n0W37J5qv.pgp
Description: PGP signature
أحمد المحمودي writes:
> On Sun, Sep 29, 2013 at 12:19:04PM -0600, Bdale Garbee wrote:
>> Daniel Schepler writes:
>>
>> > At this point, the load average shoots through the roof, and top shows
>> > a large number of make and sh processes being created. I the
Daniel Schepler writes:
> At this point, the load average shoots through the roof, and top shows
> a large number of make and sh processes being created. I therefore
> have to interrupt the build.
Which architecture and release are you trying this on?
Bdale
pgp6BbDSHszUd.pgp
Description: PGP
Russ Allbery writes:
> A conflict with openafs-client isn't really desireable, since that's a
> pretty widely installed package at sites that use AFS. Failing renaming,
> I'm inclined to split all the backup software off into a separate package
> that you can conflict with, since most people are
Ralf Treinen writes:
> Package: openafs-client,tar-scripts
> Version: openafs-client/1.6.5-1
> Version: tar-scripts/1.26+dfsg-10
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
I'll fix this by having tar-scripts conflict with openafs-client.
Bdale
pgp03KEuIF3W1
St��phane Glondu writes:
> dpkg: error processing /var/cache/apt/archives/gzip_1.6-2_armel.deb
> (--unpack):
>trying to overwrite '/usr/share/info/dir.gz', which is also in
>package ed 1.9-2
Must be a toolchain issue? It doesn't happen on any architecture I have
immediate access to.
"Adam D. Barratt" writes:
> It doesn't look like guile-2.0 has managed to build on ia64 in the
> couple of years it's been in the archive; maintainers (CCed) - is there
> any likelihood that it will?
I'm pretty much out of the loop on ia64 development at this point, but I
can't think of anyone I
"Adam D. Barratt" writes:
> Source: geda-gaf
> Version: 1:1.8.0-1
> Severity: serious
> Tags: jessie sid
>
> Hi,
>
> geda-gaf added guile-2.0 as a build-dependency, but that package does
> not exist on ia64; geda-gaf is therefore no longer buildable on that
> architecture.
Hrm. There's not much
Thijs Kinkhorst writes:
> Hi Bdale,
>
> On Fri, Jun 15, 2012 at 09:27:12AM -0600, Bdale Garbee wrote:
>> Thanks for the report. The problem is that sdcc 3.X introduces new
>> compiler features that are big problems for 8051, and sdcc is a build
>> dep for altos.
Michael Gilbert writes:
> I uploaded an nmu fixing the recent security issues. Please see
> attached patch.
Thanks.
Bdale
pgpE51sJkyUcl.pgp
Description: PGP signature
reassign 658896 libgcrypt11
thanks
I don't use LDAP, and so don't have an easy way to test this, but since
Martijn van Brummelen reports that patching libgcrypt11 the way Ubuntu
has fixes this problem, I'm reassigning the bug to libgcrypt11 for
resolution in Debian.
Regards,
Bdale
pgpVEuffq1hZ
أحمد المحمودي writes:
> Bdale, I've added gregoa's patch & pushed to git. Please upload.
Done. debian/1.8.1-2 uploaded, tagged, and pushed.
Bdale
pgpfZ7yxc2dKO.pgp
Description: PGP signature
gregor herrmann writes:
> I see; this also sounds a bit like it's not worth releasing wheezy
> with 1.6?
[shrug]
At least gschem is used to produce data for many things other than pcb,
so no, I don't really agree that it would be better to have no geda-gaf
than to have 1.6 in wheezy.
Bdale
p
gregor herrmann writes:
> Thanks, I've noted the version in NEW but for some reason I assumed
> it was targetting experimental.
> Having it in unstable now would be unfortunate (with or without this
> fix) since a new upstream version would most probably not migrate to
> testing, meaning we'd ne
gregor herrmann writes:
> I've prepared an NMU for geda-gaf (versioned as 1:1.6.2-4.3) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
Be aware that 1.8.1-1 has been uploaded to unstable and is awaiting NEW
processing.
Bdale
pgp6e10CYUEH6.pgp
Descri
Jakub Wilk writes:
> However, the doc/ directory does include the non-free GFDL
> documentation
It appears that the package was built against the full upstream tarball
and not the elided one. My bad.
FWIW, the binary package for tar does not include the GFDL documents,
this is just a source
Ben Hutchings writes:
> 'iocharset=iso8859-1' is actually the default; you would need to
> override the default by specifying 'iocharset=utf8'.
Ah, right. Yes, in that case I agree we can just lose the explicit
iocharset setting in elilo.sh.
> I can reassign this to elilo and you can set sever
"Grant H." writes:
> A couple things, intent and what actually happens are two different
> things.
Of course I understand that. But what bothers me in this and other
cases is that you're asserting that it fails the DFSG without explaining
*how* you think it fails the DFSG. And I've been around
"Grant H." writes:
> After reviewing the copyright file[1] for the package yforth[2] I
> thought that it did not qualify as free software.
Why do you say this? The intent of the author was clearly to be fully
permissive as long as attribution is retained.
For a fairly random piece of softwar
Ivo De Decker writes:
> Do you have time to upload a new version?
I've been hoping to get altos 1.1 uploaded fixing this and some other
bugs in the current code, but it just hasn't happened yet. If Keith and
I don't get that done by the first week of September, I'll upload a
simple fix for just
Ian Jackson writes:
> I'm calling for votes on the following proposal. There are
> three options - two positive versions, and FD. In summary
> A. Do not overrule release team. It is too late for automation.
> B. Do not overrule release team. Defer to them on automation.
> F. Further Dis
Andreas Beckmann writes:
> Since this directory seems to be shared by several packages
> * all of them should ship it (probably empty)
> * none should create it manually
> * none should run 'rm -rf' on it (but only on the contents specific to
> the package)
Thanks for the report.
It appears t
Andrey Rahmatullin writes:
> Also note that 1.5 was released two days ago which contains the
> updated gnulib.
Thanks for mentioning this, as I hadn't noticed yet!
Bdale
pgpukqEdsVJxF.pgp
Description: PGP signature
Thanks for the report. The problem is that sdcc 3.X introduces new
compiler features that are big problems for 8051, and sdcc is a build
dep for altos.
To fix this FTBFS, I've upload 'cc', which is a forked sdcc 2.9 built
specifically for the flavor of 8051 targets needed in altos. An upda
<#part sign=pgpmime>
On Fri, 30 Mar 2012 22:35:15 +0200, Mats Erik Andersson
wrote:
> The package is assigned to the Debian QA group, so the glibc-bsd group or
> Bdale Garbee are most likely to act on this.
I do not intend to work on the makedev package any more. On modern
Linux s
<#part sign=pgpmime>
severity 661702 important
tags 661702 +pending
thanks
On Wed, 29 Feb 2012 15:40:47 +0100, Emmanuel Kasper
wrote:
> Package: amanda-client
> Version: 1:3.3.0-1~bpo60+1
> Severity: serious
> Justification: fails to build from source
A failure to build from source on an archit
<#part sign=pgpmime>
On Fri, 24 Feb 2012 12:04:55 -0800, Don Armstrong wrote:
> I call for a vote on the kernel ABI numbering policy bug with the
> following ballot:
>
> A) The technical committee declines to override the kernel maintenance
> team's ABI numbering policy.
>
> B) Further discussio
<#part sign=pgpmime>
severity 660594 wishlist
thanks
On Mon, 20 Feb 2012 04:37:55 +0100, Andreas Beckmann
wrote:
> during a test with piuparts I noticed your package failed the piuparts
> upgrade test because dpkg detected a conffile as being modified and then
> prompted the user for an action.
On Sun, 05 Feb 2012 15:44:49 -0800, Russ Allbery wrote:
> Bdale Garbee writes:
> > On Sun, 05 Feb 2012 12:18:46 -0800, Russ Allbery wrote:
>
> >> Do we have a past precedent for how we handle publicizing tech-ctte
> >> decisions?
>
> > Not really.
>
On Sun, 05 Feb 2012 12:18:46 -0800, Russ Allbery wrote:
> Do we have a past precedent for how we handle publicizing tech-ctte
> decisions?
Not really.
A note from the package maintainers calling for help testing would seem
most appropriate to me, actually.
Bdale
pgpRkX2oMnE0k.pgp
Description:
On Thu, 02 Feb 2012 08:16:34 -0700, Bdale Garbee wrote:
> I therefore call for an immediate vote on the following ballot.
With votes from 7 of 8 committee members, all ranking A as their first
preference, the outcome of this ballot is no longer in doubt, and we have
met the required &g
On Thu, 02 Feb 2012 08:16:34 -0700, Bdale Garbee wrote:
> I also believe we've had sufficient discussion about this issue, and I
> therefore call for an immediate vote on the following ballot.
And my vote is ACB.
Bdale
pgpkaXSeffFJc.pgp
Description: PGP signature
On Thu, 2 Feb 2012 10:08:13 +0100, Stefano Zacchiroli wrote:
> I hereby submit to your attention the "dpkg multi-arch conflict".
> I believe the issue is well-known, so I describe it only briefly
> below;
I also believe we've had sufficient discussion about this issue, and I
therefore call for an
On Mon, 30 Jan 2012 17:27:17 +0200, Henri Salo wrote:
> A full-disclosure user reported issue in sudo. Please verify:
> http://seclists.org/fulldisclosure/2012/Jan/590 I hope the version
> information is correct in this bug-report. Please contact me if you
> need testing and I can help!
Thanks f
On Thu, 10 Nov 2011 22:14:59 +0100, Robert Millan wrote:
> 2011/11/10 Bdale Garbee :
> > Out of curiosity, how could this possibly lead you to believe that
> > 'grave' is an appropriate severity for this bug report? I would have
> > thought 'minor'
On Thu, 10 Nov 2011 20:27:40 +0100, Robert Millan wrote:
> Package: gcpegg
> Severity: grave
> User: debian-...@lists.debian.org
> Usertags: kfreebsd
>
> Hi,
>
> This package is uninstallable on kfreebsd-amd64 because of its dependency on
> "open" package, which nowadays is a virtual package pro
On Mon, 17 Oct 2011 20:33:22 -0500, John Hasler wrote:
> I don't have time to work on it but it should be an easy fix.
Thanks for letting me know!
I keep forgetting to update the runtime deps, guess I'm just spoiled by
how well that works with dh_shlibdeps for C apps, etc.
Bdale
pgpzatqP8hV
On Fri, 30 Sep 2011 22:21:17 +0200, Sam Geeraerts
wrote:
> The file examples/paulmon1.asm has the following notice:
>
> "Please distribute freely -- may not be sold, period."
>
> Restricting commercial distribution violates DFSG.
Since it's by the same author as the overall package and is incl
On Sat, 24 Sep 2011 20:24:46 +0200, Mònica Ramírez Arceda
wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
FYI.
Work is now focused on trying to get gnuradio upstream 3.4 packaged. I
do not expect to do any further work on the 3.2.2 packages, which are
tag 642705 +pending
thanks
On Sat, 24 Sep 2011 19:47:29 +0200, Mònica Ramírez Arceda
wrote:
> > warning: failed to load external entity "release-notes-1.0.xsl"
Already found and fixed on 30 August in our git repo with commit
e44f1ffb7104d70f5c9b9a90529ddbe1b75da074
which will be part of the
On Fri, 9 Sep 2011 09:03:04 +0200 (CEST), Petr Salinger
wrote:
> just to make it clear.
> The tar works as expected, it just emits extra warning.
Maybe a patch to this test that would allow it to succeed in the
presence of the "extra warning" makes sense for now? I would accept
such a patch if
On Thu, 8 Sep 2011 16:18:50 +0200, Josip Rodin
wrote:
> > If you ignore all transitions constraints, sure. At the same time, Debian
> > decided debian/rules must be a Makefile and you're not adjusting to cope.
>
> No, "Debian" did not decide to explicitly ban non-shell rules files at any
> point
1 - 100 of 223 matches
Mail list logo
