Bug#995055: transition: glew
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-devel@lists.debian.org This transition is triggered by an SONAME change upstream. It does not appear to have any API transition though, and seems to cause no glew-related failures. Ben file: title = "glew"; is_affected = .depends ~ "libglew2.1" | .depends ~ "libglew2.2"; is_good = .depends ~ "libglew2.2"; is_bad = .depends ~ "libglew2.1"; I've rebuilt all dependencies, with a number of unrelated FTBFS: Bugs have been submitted against all FTBFS. glew OK info-beamer : : change bd libglew1.5-dev -> libglew-dev OK phlipple: change bd libglew1.5-dev -> libglew-dev OK pymol: change bd libglew1.5-dev -> libglew-dev OK rlvm: change bd libglew1.5-dev -> libglew-dev OK asymptote: OK avogarolibs: OK ball: FTBFS (#994480) unrelated (glibc/ rpc header change) bino: OK blastem: OK blender: OK bzflag: OK casparcg-server (sid only): FTBFS (#947518) colmap: OK colobot: OK compiz-plugins-experimental: OK darkradiant: OK ddnet: OK dreamchess: OK endless-sky: OK fife: OK freeorion: OK frogatto (contrib): OK gambas3: OK gource: OK hugin: OK hyperrogue: OK k3d (sid only): FTBFS (python2 issues) kicad: OK limesuite: OK logstalgia: OK mediastreamer2: (FTFBS with gcc-11), OK megaglest : OK mesa-demos: OK mupen64plus-video-z64: OK mygui: OK open3d: OK openclonk: opencsg: OK openctm: OK openmsx:: OK otb: OK paraview: OK qutemol: OK rbdoom3bfg: OK renpy (sid only):FTBFS - needs python-sphinx rss-glx: OK scorched3d: OK slic3r-prusa OK slop: FTBFS (#994824) unrelated sludge: OK sofa-framework: FTBFS (#875184): QT4 removed spring: OK supertux: OK supertuxkart: OK trigger-rally: OK tulip: OK vice (contrib): FTBFS #994835 (jpeg support missing) vtk7: OK vtk9: OK warzone2100: OK widelands: OK cegui-mk2: OK meshlab; OK openscad: FTBFS (#994937) CGAL-related ? pcl:OK
Bundling
Dear list, Trying to plan the future for the OpenCPN package. Upstream is currently shipping a beta, and eventually it will be released and packaged. In next cycle upstream might update the wxWidgets dependency from 3.0 to 3.1.5. This is problematic, since wxWidgets offers no ABI stability for odd-numbered releases like 3.1 and there is thus no Debian packages available. Now, normally this should not be a problem since the upstream 3.2 release is due Real Soon, and OpenCPN has rather long cycles release cycles, roughly yearly. However, upstream wxWidgets seems stalled, and we are probably facing a real risk that 3.2 is still not available for next OpenCPN release in about a year. So, the question: would it be acceptable to bundle the wxWidgets 3.1.5 sources in next OpenCPN release in such a situation? Thoughts? --alec
Re: Bundling
Hi Alec, Quoting Alec Leamas (2021-09-25 17:47:04) > Trying to plan the future for the OpenCPN package. Upstream is > currently shipping a beta, and eventually it will be released and > packaged. > > In next cycle upstream might update the wxWidgets dependency from 3.0 > to 3.1.5. This is problematic, since wxWidgets offers no ABI stability > for odd-numbered releases like 3.1 and there is thus no Debian > packages available. > > Now, normally this should not be a problem since the upstream 3.2 > release is due Real Soon, and OpenCPN has rather long cycles release > cycles, roughly yearly. However, upstream wxWidgets seems stalled, and > we are probably facing a real risk that 3.2 is still not available for > next OpenCPN release in about a year. > > So, the question: would it be acceptable to bundle the wxWidgets 3.1.5 > sources in next OpenCPN release in such a situation? > > Thoughts? How do you and OpenCPN upstream expect to handle bugs for that specific embedded version of wxWidgets? Sounds more sensible to me to (coordinate with wxwidgets maintainers to have) wxWidgets 3.1.x packaged as a separate package, tracked with its proper upstream source. Then when we get near freeze it can be assessed how many of the wxWidgets branches we want to include with the upcoming stable Debian release - and include in that assessment how many packages reverse-depend on each. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bundling
Hi Jonas, On 25/09/2021 18:04, Jonas Smedegaard wrote: Hi Alec, Quoting Alec Leamas (2021-09-25 17:47:04) So, the question: would it be acceptable to bundle the wxWidgets 3.1.5 sources in next OpenCPN release in such a situation? How do you and OpenCPN upstream expect to handle bugs for that specific embedded version of wxWidgets? Sounds more sensible to me to (coordinate with wxwidgets maintainers to have) wxWidgets 3.1.x packaged as a separate package, tracked with its proper upstream source. Then when we get near freeze it can be assessed how many of the wxWidgets branches we want to include with the upcoming stable Debian release - and include in that assessment how many packages reverse-depend on each. My thinking so far has been that a wxWidgets 3.1.5 package just isn't possible since there is no ABI stability guarantee. Am I wrong? --alec
Re: Bundling
Quoting Alec Leamas (2021-09-25 18:23:42) > On 25/09/2021 18:04, Jonas Smedegaard wrote: > > Quoting Alec Leamas (2021-09-25 17:47:04) > >> > >> So, the question: would it be acceptable to bundle the wxWidgets > >> 3.1.5 sources in next OpenCPN release in such a situation? > >> > > > > How do you and OpenCPN upstream expect to handle bugs for that > > specific embedded version of wxWidgets? > > > > Sounds more sensible to me to (coordinate with wxwidgets maintainers > > to have) wxWidgets 3.1.x packaged as a separate package, tracked > > with its proper upstream source. Then when we get near freeze it > > can be assessed how many of the wxWidgets branches we want to > > include with the upcoming stable Debian release - and include in > > that assessment how many packages reverse-depend on each. > > > My thinking so far has been that a wxWidgets 3.1.5 package just isn't > possible since there is no ABI stability guarantee. Am I wrong? Lack of stable ABI means that each library change may require recompilation of reverse dependencies. This can be handled in packaging either by declaring tight dependencies (see e.g. `man dh_shlibdeps`), or by tracking library symbols and use those to resolve dependencies (see e.g. https://wiki.debian.org/UsingSymbolsFiles) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#995059: ITP: cubeb -- cross platform audio library
Package: wnpp Severity: wishlist Owner: Andrea Pappacoda X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: cubeb Version : 0.0~git20210801.6ce9596+ds-1 Upstream Author : Mozilla Foundation * URL : https://github.com/mozilla/cubeb * License : ISC Programming Lang: C++, C Description : Cross platform audio library cubeb is a cross platform audio library most notable for its use as the audio backend within Gecko, Mozilla's browser engine. It supports multiple audio backends and allows enumeration of audio devices and opening audio streams with control over latency, sample rate and more. This is a dependency of the yuzu emulator, see https://bugs.debian.org/947399 I'll upload the package to mentors soon. -BEGIN PGP SIGNATURE- iIoEARYIADIWIQRm3vFSgpkMIZnvqAGooSioqxzuSQUCYU8nlRQcYW5kcmVhQHBh cHBhY29kYS5pdAAKCRCooSioqxzuSW64AQD24d7gTbE/jpXmO4uwIfqNvlvNkdy1 5vJuIk81nphCvgD+JcWY6C3kV7VM9O0BfAA/MoFjoBM+5mmnPbMzqEU5Wws= =gpwq -END PGP SIGNATURE-
Re: No network management in LXDE task
Control: retitle -1 LXDE: Please include a user-friendly network management tool
Control: tags -1 + patch
[ Returning back to #988696 as the correct bug for this issue; dropping 994875
from CC ]
Jaycee Santos wrote (Thu, 23 Sep 2021 20:42:05 +):
> On Thursday, September 23rd, 2021 at 1:05 PM, Michael Biebl
> wrote:
> > Am 23.09.21 um 21:35 schrieb Jaycee Santos:
> > > Is there a reason why to choose gnome-network-manager over something like
> > > nm-tray for LXDE?
> >
> > I think nm-tray (being based on Qt5) is a reasonable choice for LXQT (which
> > is also Qt5 based). LXDE on the other hand uses GTK, so I think
> > network-manager-gnome is a better fit there. (both disk footprint and
> > memory usage wise)
>
> Ah. My apologies. I thought nm-applet was provided by nm-tray. I was wrong.
> I did not know that nm-applet was part of network-manager-gnome!
>
> So I agree with network-manager-gnome being a better fit for LXDE.
Regarding LXQT: this DE already installs cmst by default (an Qt based
GUI for connman, which also has a system tray icon), and since there were
no complains so far from LXQT users related to the network management tool
used, I would not touch LXQT for this.
A patch to address this issue for LXDE is attached.
Holger
diff --git a/debian/changelog b/debian/changelog
index 148cd82d..f4fba03e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,21 +1,22 @@
tasksel (3.69) UNRELEASED; urgency=medium
* Install CUPS for all *-desktop tasks, now that task-print-service is no
longer existing. Closes: #993668
+ * Install network-manager-gnome in LXDE environment. Closes: #988696
-- Holger Wansing Wed, 08 Sep 2021 22:20:05 +0200
tasksel (3.68) unstable; urgency=medium
diff --git a/debian/control b/debian/control
index 1f469e86..ec6ced7e 100644
--- a/debian/control
+++ b/debian/control
@@ -208,34 +208,36 @@ Package: task-lxde-desktop
Architecture: all
Description: LXDE
This task package is used to install the Debian desktop, featuring
the LXDE desktop environment, and with other packages that Debian users
expect to have available on the desktop.
Depends: ${misc:Depends},
task-desktop,
lightdm,
lxde,
Recommends:
lxtask,
lxlauncher,
xsane,
# libreoffice widgets using just gtk, and also accessibility needs the GTK
frontend
libreoffice-gtk3,
# Package management.
synaptic,
+# desktop network setup
+ network-manager-gnome,
# libreoffice is the best word processor / office suite at the moment
libreoffice-writer,
libreoffice-calc,
libreoffice-impress,
# make help menu work
libreoffice-help-en-us,
# make thesaurus work
mythes-en-us,
# make spellchecker work
hunspell-en-us,
# make hyphenation work
hyphen-en-us,
# gui for configuration of the print service
system-config-printer,
# orca works with lxde, adding accessibility
orca,
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: No network management in LXDE task
Am 25.09.21 um 22:05 schrieb Holger Wansing: Control: retitle -1 LXDE: Please include a user-friendly network management tool Control: tags -1 + patch [ Returning back to #988696 as the correct bug for this issue; dropping 994875 from CC ] Jaycee Santos wrote (Thu, 23 Sep 2021 20:42:05 +): On Thursday, September 23rd, 2021 at 1:05 PM, Michael Biebl wrote: Am 23.09.21 um 21:35 schrieb Jaycee Santos: Is there a reason why to choose gnome-network-manager over something like nm-tray for LXDE? I think nm-tray (being based on Qt5) is a reasonable choice for LXQT (which is also Qt5 based). LXDE on the other hand uses GTK, so I think network-manager-gnome is a better fit there. (both disk footprint and memory usage wise) Ah. My apologies. I thought nm-applet was provided by nm-tray. I was wrong. I did not know that nm-applet was part of network-manager-gnome! So I agree with network-manager-gnome being a better fit for LXDE. Regarding LXQT: this DE already installs cmst by default (an Qt based GUI for connman, which also has a system tray icon), and since there were no complains so far from LXQT users related to the network management tool used, I would not touch LXQT for this. A patch to address this issue for LXDE is attached. So now you have 3 network configuration systems involved: - ifupdown, which is still installed by default - connman, which is pulled in by the lxde package (via connman-gtk) - network-manager(-gnome), which is pulled in via task-lxde-desktop that doesn't sound like a good solution. OpenPGP_signature Description: OpenPGP digital signature
Re: No network management in LXDE task
Hi, Michael Biebl wrote (Sat, 25 Sep 2021 22:17:48 +0200): > Am 25.09.21 um 22:05 schrieb Holger Wansing: > > A patch to address this issue for LXDE is attached. > > > So now you have 3 network configuration systems involved: > > - ifupdown, which is still installed by default > - connman, which is pulled in by the lxde package (via connman-gtk) > - network-manager(-gnome), which is pulled in via task-lxde-desktop > > that doesn't sound like a good solution. Hmm, as there are no Conflicts dependencies set for those, I assumed this is no problem... ? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Re: No network management in LXDE task
Quoting Holger Wansing (2021-09-25 22:30:20) > Hi, > > Michael Biebl wrote (Sat, 25 Sep 2021 22:17:48 +0200): > > Am 25.09.21 um 22:05 schrieb Holger Wansing: > > > A patch to address this issue for LXDE is attached. > > > > > > So now you have 3 network configuration systems involved: > > > > - ifupdown, which is still installed by default > > - connman, which is pulled in by the lxde package (via connman-gtk) > > - network-manager(-gnome), which is pulled in via task-lxde-desktop > > > > that doesn't sound like a good solution. > > Hmm, as there are no Conflicts dependencies set for those, I assumed this > is no problem... ? Not only conflicting packages can be non-sensible to pull in by a task. There are no conflicts declared across httpd daemons or dns servers - because in complex scenarios they can be listening on non-default ports. Similarly, network-manager can be custom-configured to only manage some devices and connman only some other devices. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: connman does not respect /etc/network/interfaces when upgrading from buster to bullseye and more general considerations
Am 23.09.21 um 20:17 schrieb Holger Wansing: I have just installed an LXDE system to test this, and now adding network-manager-gnome, installs 24 new packages, taking 39 MB of additional disk space, according to the apt-get output I might consider splitting off network-manager's /usr/share/locale into an (optional, Recommends/Suggests) network-manager-l10n package. The locales take up about 8,5 MB of disk space. While I don't necessarily think that 8,5 MB are actually that much of an issue for desktop installations, trimming down the on disk footprint might make network-manager more suitable for more constrained environments. There is also a (somewhat stale) MR [1] for network-manager asking for the individual plugins to be split into separate packages to make it possible to trim down the dependency chain. If there is real demand for it, we could revisit that. Michael [1] https://salsa.debian.org/utopia-team/network-manager/-/merge_requests/4 OpenPGP_signature Description: OpenPGP digital signature
Re: partman, growlight, discoverable partitions, and fun
It supports MBR, GPT, and APM: https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123 (sorry for the gmail-style top posting; i can't find your mail in my mbox for whatever reason) Any other partition schemes ought be trivial to add; they've not been added yet simply because I don't have means with which to test them. Looking at the "partition types" section of the Linux configuration, I see: Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris x86, Unixware, Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68. Looking at the disk-label code from partman, I see: gpt, msdos, amiga, atari, mac, sun So the only ones covered by partman and not covered by growlight would be: amiga, atari, sun, and mac (if mac is not the same as APM). I don't see any difficulty in adding these four, so long as there's someone with an Amiga or ATARI who'd be willing to test them out. If there are no such people, is it that important? On Thu, Sep 23, 2021 at 5:29 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello! > > On 9/23/21 22:57, nick black wrote: > > I am just finishing up the implementation of Discoverable GPT > > Partitions [0] in my growlight tool, and it seems a good time to > > see if I can push this discussion [1] forward. > > Does it support partition tables other than GPT, in particular all > of the partition tables that parted supports? > > If not, I don't think it would be a viable replacement for partman. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaub...@debian.org > `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > -- nick black to make an apple pie from scratch, one need first invent a universe.
Re: partman, growlight, discoverable partitions, and fun
Marco d'Itri left as an exercise for the reader: > On Sep 24, Marc Haber wrote: > > > But maybe an alternative? I find the partitioning step one of the most > > error-prone and hard-to-use parts of non-trivial Debian installations. > And the preseeding syntax is as powerful as it is inconvenient. > I had not heard of growlight before yesterday, but from what I have read > I think that it is very promising. > > Implementing support for more partition formats, if missing, should be > rather easy. > But which ones do we need for architectures which are not actually dead? So, as I responded to Adrian [0], the only missing partition types appear to be amiga, atari, and sun. Adding them ought be simple enough, though I'd need testers with the hardware, or access to the hardware. My biggest worry personally (aside from the realpolitik of getting this change through) regards the automated partitioning language available through the preseed system. Trying to emulate this bug-for-bug is a non-starter, I think, both from a technical and quality-of-life standpoint. If the emulation can't be perfectly accurate, I don't think it ought be attempted for such a critical, delicate procedure. If faithfully honoring the preseed language is seen as a hard requirement (not that I've heard this from anyone), it's probably not happening. How important is that? I could do a limited implementation, perhaps, where I clearly error out on a spec I can't handle, falling back to partman. If, on the other hand, it seems time to revamp the automatic partitioning specification DSL, I could probably get behind that. Maybe even the old one; I'd need see how complex it is (I recall some pain trying to write complicated partman specs in the past, but it was many years ago). So...how do I go about making this happen? fwiw, I'm but a lowly DM, not a DD. --nick [0] https://lists.debian.org/debian-devel/2021/09/msg00365.html -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: connman does not respect /etc/network/interfaces when upgrading from buster to bullseye and more general considerations
Hi Michael, On Sun, Sep 26, 2021 at 01:01:28AM +0200, Michael Biebl wrote: > Am 23.09.21 um 20:17 schrieb Holger Wansing: > > > I have just installed an LXDE system to test this, and now adding > > network-manager-gnome, installs 24 new packages, taking 39 MB of additional > > disk space, according to the apt-get output > I might consider splitting off network-manager's /usr/share/locale into an > (optional, Recommends/Suggests) network-manager-l10n package. The locales > take up about 8,5 MB of disk space. I agree that 8.5MB are not much these days but if it helps to accept network-manager as a unique default this would probably a sensible step. > While I don't necessarily think that 8,5 MB are actually that much of an > issue for desktop installations, trimming down the on disk footprint might > make network-manager more suitable for more constrained environments. > > There is also a (somewhat stale) MR [1] for network-manager asking for the > individual plugins to be split into separate packages to make it possible to > trim down the dependency chain. > > If there is real demand for it, we could revisit that. In the same way I wrote above: If increases the acceptance for NM - yes, this sounds good. Kind regards Andreas. -- http://fam-tille.de
