Re: AMDGPU+OpenCL with Debian?

[Rebecca N. Palmer]

Summary: try installing mesa-opencl-icd.

It's a known issue that there is currently no way for an OpenCL-using 
package to ask for "the correct OpenCL driver for this hardware": it can 
ask for "any OpenCL driver" (letting apt choose) or "an OpenCL driver 
chosen by the packager", either of which might be the wrong one for the 
user's hardware.


Debian currently has:
beignet-opencl-icd - Intel GPUs
mesa-opencl-icd - AMD/ATI GPUs (not sure exactly which ones - very new 
ones might need ROCm)

pocl-opencl-icd - CPUs
Nvidia needs non-free.

I proposed [0] fixing this by creating a metapackage for "all OpenCL 
drivers" (similar to the ones for graphics).  However, having unusable 
OpenCL drivers installed can trigger bugs: [1] in llvm, and some 
applications that treat "no hardware for this driver" as "fatal error" 
instead of "try the next driver".


[0] 
https://alioth-lists.debian.net/pipermail/pkg-opencl-devel/Week-of-Mon-20140203/76.html

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852746

Re: AMDGPU+OpenCL with Debian?

[Michael Kesper]

Hi Moritz,

On 18.06.19 22:55, Moritz Mühlenhoff wrote:
> You may find https://phabricator.wikimedia.org/T148843/#5078403
> (and later) interesting, 

This seems to require wikimedia authentication.
Is there some information publicly available about it?

Best wishes
Michael



signature.asc
Description: OpenPGP digital signature

Quotation Inquiry #RFQ170619E - New Supplier

[Hidroconta Trading Ltd .]

Hello,

Our partners referred your company to us. Regarding your great products.
Please see required products, quantity and specifications as attached.

Kindly give us your lowest possible prices for FCL shipment.


Best Regards,

Wanda Rodriguez
Purchase Assistant

Hidroconta Trading Ltd.
Av. de Sta. Catalina,
60, 30012 Murcia, Spain
Phone: +34 968 26 77 66
Fax: +34 968 26 77 06

Bug#930722: arc, arcanist: Both ship arc binary

[Julian Andres Klode]

Package: arc,arcanist
Severity: serious

arc: /usr/bin/arc
arcanist: /usr/bin/arc

One of them needs to be renamed, or both.

-- System Information:
Debian Release: buster/sid
  APT prefers eoan
  APT policy: (991, 'eoan'), (500, 'eoan'), (500, 'cosmic-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-15-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#930723: ITP: arduino-sanguino -- atmega644 files for use with Arduino

[Bas Wijnen]

Package: wnpp
Severity: wishlist
Owner: 3-D printer team <3dprinter-gene...@alioth-lists.debian.net>

* Package name: arduino-sanguino
  Version : 1.0.0
  Upstream Author : Kristian Sloth Lauszus 
* URL : http://lauszus.github.io/Sanguino/
* License : GPL-3+
  Programming Lang: C++
  Description : Platform files for Arduino to run on ATmega644

This package contains files for compiling programs for the ATmega644
microcontroller.

This is useful for people who want to use the Arduino programming environment
with the atmega644 microcontroller as the target hardware.

I will maintain this within the 3-D printer team.

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Ian Jackson]

> On Mon 17 Jun 2019 at 06:21pm +0200, Helmut Grohne wrote:
> > Presently, no. I attempted using it, but I feel that the extra
> > complexity did not help my use case. dgit solves a difficult problem and
> > that comes at a cost. Verification of source integrity is much more
> > difficult to understand with dgit (and it presently seems to have a
> > trust root in the ca business). The integrity checking performed by
> > apt-get source on the other hand is quite easily explained (if you
> > assume gpgv).

On this, Sean writes:

> Can I ask whether you think it would help if dgit was more verbose about
> the verification it was doing?  Telling you what the ftpmaster API was
> telling it, or something.

This might be of some use but I don't think it is a real solution for
Helmut.

> The commercial SSL thing is indeed a problem (#790093).

FTAOD: I have a memory that in response to Hector Oron's message #20
in that bug, I did try to have a conversation on debian-admin, but
that I found that conversation very frustrating.  I did not feel that
the DSA members I was talking to were listening very well.  Probably,
they felt I was rude.  I gave up. [1]

I would really appreciate it if someone else (who understands the
problem) would have a go.

Hector: If it would be useful to you, I could tell you a set of dgit
configuration settings to have it use the apt repository fetching
method.  That would rely, therefore, on the existing apt dsc
verification system (based on Release files etc.), and not on the
ftpmaster api service.

This is not the default because (1) it means downloading the whole of
the Sources for a distribution just to obtain one package and (2) it
has a much greater risk of skew due to getting stale data.  If more
people want this mode of operation I could provide a more cooked way
to specify it, although I think it is suboptimal to fixing #790093.

> >  I
> > occasionally look into history of packages to figure something out. For
> > this case, dgit is not useful due to its low adoption and being young.
> > On the other hand, debian/changelog often suffices here.

dgit is not young.  It was invented in August 2013 in Vaumarcus by
Joey Hess and I.  So it is nearly 6 years old.

Low adoption of "dgit push" is indeed a serious problem.

> For the history thing, after you `dgit clone`, `git fetch vcs-git` will
> get you the maintainer's history for browsing.  That's about as easy as
> debcheckout.

It's not really what Helmut wants, though.

Ian.

[1] I don't appear to have saved a transcript of the conversation.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Ian Jackson]

Ian Jackson writes ("Re: The Difference between debcheckout and dgit and what 
they try to accomplish"):
> Hector: If it would be useful to you, I could tell you a set of dgit
> configuration settings to have it use the apt repository fetching
> method.  That would rely, therefore, on the existing apt dsc
> verification system (based on Release files etc.), and not on the
> ftpmaster api service.

I meant "Helmut".  Sorry to get that wrong!

(I will 

Ian.

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Colin Watson]

On Wed, Jun 19, 2019 at 01:57:39PM +0100, Ian Jackson wrote:
> FTAOD: I have a memory that in response to Hector Oron's message #20
> in that bug, I did try to have a conversation on debian-admin, but
> that I found that conversation very frustrating.  I did not feel that
> the DSA members I was talking to were listening very well.  Probably,
> they felt I was rude.  I gave up. [1]

Is it at all likely that the ftpmaster api service might migrate away
from Let's Encrypt at this point?  I would assume probably not.  In that
case, you could at least make the situation substantially better with no
further DSA work required by pinning the appropriate LE root certificate
in dgit.  While that still means that LE could subvert the service, it
would prevent anyone else who operates one of the many CAs in
ca-certificates from doing the same.  Does that help?

-- 
Colin Watson   [cjwat...@debian.org]

Re: binutils security support (Re: fixing debian-security-support upgrades from stretch (for good))

[Christoph Martin]

Am 14.05.19 um 23:39 schrieb Moritz Mühlenhoff:
> Holger Levsen  schrieb:
>> (and yes, I also agree this is quite a desaster, just like
>> kde4libs/khtml only is suitable for trusted content, which IOW means,
>> one should not use konqueror or kmail on the interweb.)
> 
> That is the upstream status quo and not in any way specific to Debian,
> we're just the only ones transparent about it instead of wiping it
> under the carpet.

Thanks for the clarification.

It would be helpful, if this remark about the missing *upstream* support
was in debian-security-support in addition to the line

>   Details: Not covered by security support

It took me some time find the remark in debian-devel.

Christoph



signature.asc
Description: OpenPGP digital signature

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Russ Allbery]

Colin Watson  writes:

> Is it at all likely that the ftpmaster api service might migrate away
> from Let's Encrypt at this point?  I would assume probably not.  In that
> case, you could at least make the situation substantially better with no
> further DSA work required by pinning the appropriate LE root certificate
> in dgit.

debian.org already publishes a CAA record, which conveys that information
(although has its own verification concerns, but I think debian.org is
using DNSSEC so you can verify the record that way).  It says that all
debian.org hosts will only use certificates from either LE or Amazon:

gwaihir:~$ host -t caa debian.org
debian.org has CAA record 0 iodef "mailto:d...@debian.org";
debian.org has CAA record 128 issuewild ";"
debian.org has CAA record 128 issue "letsencrypt.org"
debian.org has CAA record 128 issue "amazon.com"

-- 
Russ Allbery (r...@debian.org)   

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Colin Watson  writes:
>> Is it at all likely that the ftpmaster api service might migrate
>> away from Let's Encrypt at this point?  I would assume probably
>> not.  In that case, you could at least make the situation
>> substantially better with no further DSA work required by pinning
>> the appropriate LE root certificate in dgit.

Russ> debian.org already publishes a CAA record, which conveys that
Russ> information (although has its own verification concerns, but I
Russ> think debian.org is using DNSSEC so you can verify the record
Russ> that way).  It says that all debian.org hosts will only use
Russ> certificates from either LE or Amazon:

Russ, you may be more up to date on webpki than I am.
Does that say anything about which root letsencrypt will chain to?
I.E. can letsencrypt change what their chain looks like?

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Russ Allbery]

Sam Hartman  writes:
>> "Russ" == Russ Allbery  writes:

> Russ> debian.org already publishes a CAA record, which conveys that
> Russ> information (although has its own verification concerns, but I
> Russ> think debian.org is using DNSSEC so you can verify the record
> Russ> that way).  It says that all debian.org hosts will only use
> Russ> certificates from either LE or Amazon:

> Russ, you may be more up to date on webpki than I am.
> Does that say anything about which root letsencrypt will chain to?
> I.E. can letsencrypt change what their chain looks like?

It does, but that's because it's not the greatest for clients, which makes
it a touch hard to use on the dgit side.

My understanding is that the CAA record is intended as a constraint on
CAs, not really a verification step for clients.  A CAA is not supposed to
issue certificates for a domain that has a CAA record and that doesn't
list that issuer.  Because of that, the interpretation of the CAA record
is somewhat up to the domain.  It's intended to protect you against
legitimate CAs being socially-engineered to issue a certificate for your
domain.

That also means there's no easy way to map a CAA record value to a
specific certificate or certificate chain.  It therefore doesn't solve the
dgit problem directly, but it does provide some verification that
debian.org domains are only going to use LE (and Amazon) certs unless that
CAA record changes, and therefore dgit could do client-side certificate
pinning to those two certificate chains, at the cost of having to manually
track changes to those chains.

-- 
Russ Allbery (r...@debian.org)   

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Wouter Verhelst]

On Mon, Jun 17, 2019 at 11:47:38AM +0100, Sean Whitton wrote:
> We could try to write a tool which tries to guess and convert (e.g.) the
> dgit view with your changes into a maintainer workflow, but there are
> large obstacles to this working reliably.  For example, there exist edge
> cases such that there is no algorithm which can determine, for any
> possible Debian source package tree committed to git, whether it is
> patches-applied or patches-unapplied.  And there are so many small
> variations on workflows that such a tool would have to be very complex.

What if you took away the necessary guesswork?

Have dgit support a field in debian/control that, if it exists, explains
to dgit (and any other tool that might care) what the workflow type is.
This would require a categorization of all the possible git layouts, and
would initially obviously not support all of them.

But once it exists, it would allow behaviour for a hypothetical "dgit
create-merge-request" command or some such, where if the field exists in
debian/control a merge request is posted to salsa in the correct
fashion; and if the field does *not* exist in debian/control, it would
then instead simply be a wrapper around 'git format-patch' and/or 'git
send-email'.

This would, as an aside, also allow maintainers to express that they
would prefer merge requests in salsa over patches in the bts, so would
have use beyond dgit.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Ansgar Burchardt]

Russ Allbery writes:
> Colin Watson writes:
>> Is it at all likely that the ftpmaster api service might migrate away
>> from Let's Encrypt at this point?  I would assume probably not.  In that
>> case, you could at least make the situation substantially better with no
>> further DSA work required by pinning the appropriate LE root certificate
>> in dgit.
>
> debian.org already publishes a CAA record, which conveys that information
> (although has its own verification concerns, but I think debian.org is
> using DNSSEC so you can verify the record that way).  It says that all
> debian.org hosts will only use certificates from either LE or Amazon:

The CAA record does not indicate a future commitment and could change at
any time.  If you want to rely on debian.org to use some specific CAs,
you would have to ask DSA.

(Nor does the CAA record indicate that all currently valid certificates
must come from the listed CAs; the CAA record could have been different
when those were issued.)

Ansgar

Programs contain ads - acceptable for packaging for Debian?

[Bagas Sanjaya]

Hello Debian Developers,

Suppose that an upstream has released a program which its license 
conforms to DFSG (named ZZZ), but when I test it, ads placed by the 
upstream appear (such as pop up ads). Since ads can affect user 
experience of ZZZ, but at the same time the upstream get paid by ad 
networks which he place the ads into ZZZ, would it acceptable to package 
ZZZ for Debian?


Regards, Bagas