On Sun, 2023-12-31 at 10:31 +0100, Helmut Grohne wrote:
> On Sun, Dec 31, 2023 at 09:08:31AM +0100, Abou Al Montacir wrote:
> > So the new changes triggered more than 2.5k lintian warning.
> > https://udd.debian.org/lintian/?packages=lazarus
>
> Are you referring to those
>
On Sun, Dec 31, 2023 at 09:08:31AM +0100, Abou Al Montacir wrote:
> So the new changes triggered more than 2.5k lintian warning.
> https://udd.debian.org/lintian/?packages=lazarus
Are you referring to those
arch-dependent-file-not-in-arch-specific-directory only?
> The issue is that Lazarus does
Hi Helmut,
On Tue, 2023-12-26 at 06:07 +0100, Helmut Grohne wrote:
> > If we do so, then the PTS will complain, but why not, I'll let you then
> > suggest
> > next step.
>
> Yes, please. As you say this, I now guess a possible sequence of events
> that made this happen (hypothesis).
So the new
On Wed, 2023-12-27 at 12:01 +0100, Helmut Grohne wrote:
> > Please review this patch, and I'll upload it if you find it OK.
>
> Reviewing M-A:same annotations is hard. Would you mind uploading to
> unstable (as the multiarch hinter does not look at experimental) and if
> it complains about
On Tue, Dec 26, 2023 at 10:36:16PM +0100, Abou Al Montacir wrote:
> Please review this patch, and I'll upload it if you find it OK.
Reviewing M-A:same annotations is hard. Would you mind uploading to
unstable (as the multiarch hinter does not look at experimental) and if
it complains about
On Tue, 2023-12-26 at 06:07 +0100, Helmut Grohne wrote:
> In principle, I agree here. For them to become M-A:same they must first
> become A:any as M-A:same is not valid for A:all. The question that is
> not clear to me is whether this is worth the effort, i.e. whether it
> poses a practical
On Mon, Dec 25, 2023 at 10:16:13PM +0100, Abou Al Montacir wrote:
> On Sun, 2023-12-24 at 10:08 +0100, Helmut Grohne wrote:
> > lazarus-ide-2.2, lazarus-ide-gtk2-2.2, lazarus-ide-qt5-2.2,
> > lcl-utils-2.2, lcl-units-2.2, lcl-nogui-2.2, lcl-gtk2-2.2 and
> > lcl-qt5-2.2 are A:any and implicitly
Hi Helmut,
On Sun, 2023-12-24 at 10:08 +0100, Helmut Grohne wrote:
> Hi,
>
> On Sun, Dec 24, 2023 at 08:51:54AM +0100, Abou Al Montacir wrote:
> > Just like lcl, lcl-2.2 is also a virtual package.
>
> This is technically wrong. The term "virtual package" refers to a binary
> package name that
Hi,
On Sun, Dec 24, 2023 at 08:51:54AM +0100, Abou Al Montacir wrote:
> Just like lcl, lcl-2.2 is also a virtual package.
This is technically wrong. The term "virtual package" refers to a binary
package name that is provided by some package but doesn't exist as a
.deb. Both lcl and lcl-2.2 exist
Hi Helmut,
Just like lcl, lcl-2.2 is also a virtual package.
If I look to all other virtual packages, they are Arch: all, and I tend to agree
with that.
However, I'm not very familiar with multi-arch subtleties.
So if you want to fix this, please provide a proposal for then entire set of
Package: lcl
Version: 2.0.2+dfsg-2
Severity: important
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:ddrescueview
lcl is Multi-Arch: foreign. This is an assertion that interfacing with
it works the same way irrespective of its architcture. Moreover, it's an
empty
11 matches
Mail list logo
