(beignet's FTBFS is #974792, my previous attempts to fix it are in
Salsa, and I was planning to remove it and accept that older hardware
would only be able to use CPU (pocl) OpenCL. Please use that bug for
further discussion of that.)
I'd leave the loader packages alone, i.e. ocl-icd-libopenc
On 18/06/2023 03:37, Paul Wise wrote:
Presumably any of the OpenCL ICDs work for most packages?
For most OpenCL-using *packages* but not most *hardware*. (Except for
pocl-opencl-icd, which works nearly everywhere but is slow.)
Perhaps there should be a default-opencl-icd virtual package?
I don't consider the lack of .xls in pandas worth a freeze exception,
but consider it reasonable for others to disagree with that.
As noted in the bug, there are some (possibly not-technically-valid)
.xlsx files that xlrd 1 can open but openpyxl can't - _pandas_ won't be
able to open those eit
Ask the release team ("unblock" bug against release.debian.org, or
debian-release@l.d.o): they can override the automated checks.
Johannes Schauer wrote:
In particular, in the "CI" column, look for those rows where the first line
shows exactly "✔-" -- those packages have to be excluded. Failures are fine and
even both missing is fine but a checkmark followed by a minus triggers that
bug.
Neutral/missing ("⛔-") is also bad
Control: retitle -1 UDD/dmd: fails to load when debci data is missing
The problem isn't the number of packages, but some specific packages
that can't be displayed even when they are the only package requested:
https://udd.debian.org/dmd/?email1=&email2=&email3=&packages=node-file-entry-cache&ig
gregor herrmann wrote:
This link and the whole check would be helpful only for not-migrated
alioth lists which don't work anymore but I guess lintian has no
chance to make this discrimination.
Lintian already has a list of individual known-bad addresses
(data/fields/bounce-addresses, tags *-ca
This is an issue with the checking system, not a bug in your package.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955268
On 02/08/2019 19:09, Ian Jackson wrote:
Sam Hartman writes ("Re: tag2upload (git-debpush) service architecture -
draft"):
Can you outline how to get from the dsc to a verification of the tag
signature without contacting the dgit server?
Sure.
Split the tag object daa at the relevant - bo
e commit
tag debian/1.3.2-6
tagger Rebecca N. Palmer 1549574096 +
beignet Debian release 1.3.2-6
[signature deleted]
Bastian Blank wrote:
The output of all operations obviously needs to be reproducible to be signed.
Other parties could re-run the tag2upload transformation to verify it,
On 31/07/2019 17:08, Ian Jackson wrote:
.dsc generation is complicated, slow, and inconvenient.
In what circumstances is it slow enough to matter?
My measurements, in a sid chroot:
source .orig .debian origcreate dpkg-b.
size size time time
dgit(native)4M 0.3sec
dak
-- ? Breaks "get sponsor name from .dsc" tools
abcde
On 30/07/2019 16:54, Bastian Blank wrote:
On Sun, Jul 28, 2019 at 07:05:49PM +0100, Rebecca N. Palmer wrote:
That suggests that working towards requiring the SHA-256 mode of git (which
at least sort of exists since 2.21 [2], but I
On 28/07/2019 20:01, Sean Whitton wrote:
When I read your first e-mail what I thought you had in mind was just
this -- having git-debpush compute a stronger hash of the tree object
and add that to the tag metadata, ignoring commit objects.
Of the files in the signer's repository, not of an actu
On 28/07/2019 16:18, Ian Jackson wrote:
What it amounts to is a parallel Merkle tree to the
git one, just with a different data format and a better hash.
Not really: it wouldn't need the history tree structure (in Git terms
[0], it would be a tree object not a commit object), and if we use
ta
On 28/07/2019 10:58, Bernd Zeimetz wrote:
On 7/27/19 8:16 PM, Rebecca N. Palmer wrote:
As a way to avoid relying on SHA-1, would it work to have git-debpush
include a longer hash in the tag message, and tag2upload also verify
that hash?
what exactly would you create that long hash of?
The
As a way to avoid relying on SHA-1, would it work to have git-debpush
include a longer hash in the tag message, and tag2upload also verify
that hash?
On 01/07/2019 18:10, Enrico Weigelt, metux IT consult wrote:
On 19.06.19 09:09, Rebecca N. Palmer wrote:
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 trigge
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
Changes from dagre to this fork are summarized at [0]. It looks like
Gitlab use this fork because Mermaid does [1] and the fork author is a
major Mermaid contributor [2].
A few packages currently use the original dagre(-d3), but none run its
full build process:
firefox/firefox-esr/thunderbi
The monodevelop package has been removed from Debian, as there were not
enough maintainers to handle its large number of dependencies (the
debian-cli list has received nothing but spam for nearly 2 years):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893860
It remains available from upstr
Would packaging Regal solve any of this?
https://github.com/p3/regal
It claims to implement OpenGL on top of OpenGL ES, but I don't know if
it is complete enough or efficient enough to be useful in this context.
Dmitry Shachnev wrote:
We do not have a final list yet, but packages that may ge
Lisandro Damián Nicanor Pérez Meyer wrote:
El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
I have an embedded Intel card right now :)
Same here, 10 years old machine with an embedded Intel video card. I don't
think I can expect it to work with GLES.
Wikipedia says I
Package: lintian
Version: 2.5.112
Patrice Duroux wrote:
I was surprise to discover such case of the following package:
https://tracker.debian.org/pkg/libnfs
for which the unstable and testing versions have the ~exp1 suffix and
the head of the corresponding changelog.Debian.gz is:
libnfs (2.0.
This was recently discussed on the -backports list:
https://lists.debian.org/debian-backports/2018/10/threads.html#00014
Sorry - I was looking at the "Bug reports" link which is the binary
package, not the source package, so missed ublock-origin #877040 and
debianbuttons #870344.
There's also #866997 requesting that mozilla-devscripts provide tools
for packaging WebExtensions, which has patches.
Vincent Bernat wrote:
WebExtensions are backed by a standard draft:
https://browserext.github.io/browserext/. So, situation is expected to
improve in the future.
Mozilla have explicitly said that "Extensions created with the new
standard[...]won’t break in new Firefox releases." [0]
It has pre
Anthony DeRobertis wrote:
The only thing
I've seen is
Recommends: cpu-microcode-all | cpu-microcode
and having a cpu-microcode-all package that Depends on both, and having
the two real package Provides cpu-microcode. If I remember correctly,
Xorg did this at one point for video drivers (may
On 10/03/17 00:10, Jeremy Bicha wrote:
I think a lot of those appstream installs are from KDE and GNOME which
install plasma-discover and gnome-software by default.
Do those things display AppStream "packages related to this hardware" by
default?
(beignet-opencl-icd isn't a valid test because
appstream itself is installed on ~60% of sid/stretch desktops [0], but
isenkram on only ~5% (and most of those are the -cli version).
When beignet-opencl-icd added AppStream metadata (black line in [1]),
there was no noticeable increase in its installs. As it's for popular
hardware (~33% of s
For investigating a crash, you may not need to recompile: first
try installing the debug symbols package (icedove-dbg).
For already known bugs, see
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=icedove
If you still want to recompile, you're missing
$ sudo apt-get install build-
Would it be possible/reasonable (at least for stretch) to have the
installer detect this and ask "your hardware appears to be too new for
this release, would you like to enable -backports?"
On 04/07/16 23:38, Ben Hutchings wrote:
As I understand it, xserver-xorg-video-modesetting should be use
It outputs "lib: lib". No arch triplet. Is this expected?
Yes; you probably want ${CMAKE_INSTALL_FULL_LIBDIR}.
http://www.cmake.org/cmake/help/v3.1/module/GNUInstallDirs.html
https://anonscm.debian.org/cgit/pkg-opencl/beignet.git/tree/debian/patches/Enable-multiarch.patch?id=a4be256b30625db8829a
Why? Which attack do you envision[...]that would
be thwarted by https but not by signed commits?
I don't; I see https as easier and hence more likely to actually get
used in practice.
Telling users to use the existing https:// instead of git:// is a simple
change to the wiki; enabling https on
While we're on the subject of git security...should we stop recommending
that non-account-holders use git:// (most efficient, but insecure
against MITM unless you manually check the commit number) in preference
to https:// (at least some security)?
https://wiki.debian.org/Alioth/Git#Accessing_r
What's the preferred way to set Built-Using:
http://sources.debian.net/src/chromium-browser/42.0.2311.135-2/debian/control/?hl=82#L82
,
http://sources.debian.net/src/binutils/2.25-7/debian/rules/?hl=998#L998
, or something else?
The existing statically-linked-binary /
shared-lib-without-depe
And as DM I can't upload to experimental.
Sometimes in freeze time I am getting emails from Ubuntu users which wants to
have new upstream version in upcoming Ubuntu release.
DMs can upload to experimental, and Ubuntu will sync from there if you
ask them to: see e.g. https://tracker.debian.org/p
As a transitional measure, you could patch lcmaps so it searches
/usr/lib/lcmaps with lower priority than ${libdir}/lcmaps, so that these
older plugin packages continue to work for a couple of years.
openscenegraph does that (currently openscenegraph-plugin-citygml-shared
and libopenscenegraph's
There's no limit on age, but an FTBFS is a serious bug; there are
regular automated checks for this (e.g. https://bugs.debian.org/768691
), but manual reports are also welcome.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact l
https://wiki.debian.org/ArchitectureSpecificsMemo
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546f3ec4.5030...@zoho.com
Anyone else seeing this problem?
$ git pull
fatal: unable to access
'https://anonscm.debian.org/git/pkg-opencl/beignet.git/': Failed to
connect to anonscm.debian.org port 443: Connection refused
https://alioth.debian.org/ in a browser gives "can't establish a connection"
--
To UNSUBSCRIBE,
Has there already been any further discussion about the solution for Xul
extensions packaged in Debian?
I haven't looked for the official discussion, but extensions have been
updated in stable (to a new upstream version if necessary) when a
browser update would otherwise break them: see e.g. #74
It has been recently stated [0-1] that backports is enabled by default
in Jessie.
1. Does that mean that if pkgX is in jessie-backports but not jessie,
"apt-get install pkgX" will install it from -backports?
2. If so, when (if ever) is it appropriate to deliberately invoke that
behaviour by
Bottom line: the vectorisation provided -O3 can provide big speed ups to
some scientific programs, but it is ineffective on Debian because by
necessity it tells gcc to compile code for lowest common denominator CPU
which doesn't have the necessary instructions.
Ineffective on i386, but amd64 alw
Do they now require login, or is the server down?
simgear$ git pull
fatal: unable to access
'https://alioth.debian.org/anonscm/git/collab-maint/simgear.git/': The
requested URL returned error: 403
http://anonscm.debian.org/viewvc/pkg-llvm/emscripten/trunk/:
An Exception Has Occurred
The roo
44 matches
Mail list logo
