Bug#909645: ITP: golang-github-maraino-go-mock -- A mocking framework for the Go Programming Language
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: golang-github-maraino-go-mock Version : 0.0~git20180321.4c74c43-1 Upstream Author : Mariano Cano * URL : https://github.com/maraino/go-mock * License : MIT Programming Lang: Go Description : A mocking framework for the Go Programming Language Go-mock is a Golang framework for easily mocking an interface. It defines various stubs and adapters that can be used to simulate code on the other side of the interface. It is packaged as a dependency of gockle, a mockable Cassandra driver for Go.
Re: julia_1.0.0-1_amd64.changes REJECTED
Hi Bastian I sponsored Lumin's original upload of Julia 1.0.0-1 and worked with him closely, reviewing the commits leading up to the upload. In the meantime, Lumin has become a Debian Developer and uploaded the subsequent versions himself, although still with some input and testing from me. I thought Lumin had made it clear enough that being able to obtain a stacktrace from within Julia is actually a feature [1]. One of Julia's tests checks this, and hence autopkgtests fail if debug symbols are missing from sys.so, which is compiled from .jl files, not C/CXX source. However, Lumin has now updated the comments in debian/rules [2] to be more explicit. For reference, the RM bug Lumin referred to in his previous mail is #903548. Regards Graham [1] https://docs.julialang.org/en/v1.0.0/manual/stacktraces/ [2] https://salsa.debian.org/julia-team/julia/commit/e7295f3eddffa8bd525145e8be245d9722c25479
Re: julia_1.0.0-1_amd64.changes REJECTED
On Wed, Sep 26, 2018 at 12:52:41PM +0200, Graham Inggs wrote: > I thought Lumin had made it clear enough that being able to obtain a > stacktrace from within Julia is actually a feature [1]. One of Julia's > tests checks this, and hence autopkgtests fail if debug symbols are missing > from sys.so, which is compiled from .jl files, not C/CXX source. It's not clear why the debug symbols are necessary to be in the binary and not detached as with most other binaries in the archive. -- WBR, wRAR signature.asc Description: PGP signature
Re: julia_1.0.0-1_amd64.changes REJECTED
Lumin writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> 1. Isn't "incomplete backtrace" a sensible reason to keep debug symbols?
>Policy said "should" but not "must". Please tell me what I can do in
>order to help improve the src:julia package to satisfy the requirements?
My main concern here is this: AFAICT this package has been REJECTed
solely for this reason. Why is this bug[1] a reason for a REJECT ?
ISTM that it should be filed in the BTS and handled like a normal bug.
[1] Assuming it is a bug. The discussion here suggests to me that it
is, but it is really unhelpful to be having it on debian-devel in the
context of an ftpmaster REJECTion.
Ian.
Re: julia_1.0.0-1_amd64.changes REJECTED
Graham Inggs writes ("Re: julia_1.0.0-1_amd64.changes REJECTED"):
> I thought Lumin had made it clear enough that being able to obtain a
> stacktrace from within Julia is actually a feature [1]. One of Julia's
> tests checks this, and hence autopkgtests fail if debug symbols are
> missing from sys.so, which is compiled from .jl files, not C/CXX source.
Perhaps the autopkgtest needs to depend on the relevant debug
package, then ?
Ian.
Re: [Pkg-julia-devel] julia_1.0.0-1_amd64.changes REJECTED
Hi Andrey On 26/09/2018 13:13, Andrey Rahmatullin wrote: It's not clear why the debug symbols are necessary to be in the binary and not detached as with most other binaries in the archive. I believe the debug symbols can be detached, but we would still need to depend on them, so I don't think it worth be worth creating a separate debug package. Regards Graham
request to collaboratively maintain rss2email
Hi there, (CC -devel FYI) Whilst chasing down a bug I noticed rss2email seems to be in a little bit of trouble. I see it is not team-maintained, you are not listed as LowThresholdNMU and it has not been updated since at least the Alioth VCS URIs were turned off. Would you be happy to collaboratively maintain rss2email? If so I am happy to start the bureaucracy-ball rolling by creating a Salsa project debian/rss2email and mirroring the former-Alioth git refs into it. Best wishes -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
epoch bump request for gnome-calculator
Emailing both debian-devel and the Debian GNOME mailing list. I am requesting project approval for me to upload gnome-calculator with an epoch. Five years ago, gcalctool 6.4 was renamed to gnome-calculator and renumbered to 3.8. This seemed like a clear case for an epoch since this was a permanent change in the version numbering scheme. I made this change in the Debian VCS and uploaded it to Ubuntu. At the time I did not have upload rights to Debian and Ubuntu has deadlines. A month later, a Debian GNOME team member recognized that we could use a dh_gencontrol hack [1] to only add the epoch to the gcalctool transitional package and we didn't need an epoch for gnome-calculator. Similarly, we could have used this hack for many of the gnome-games packages when they were split into separate source packages but we didn't because we uploaded them before we made this change. (The version numbering didn't change but gnome-games had an epoch we didn't need to carry to the new packages.) More recently, I have worked to reduce the difference between Debian and Ubuntu packaging for many GNOME packages. It gets very tedious to need to upload gnome-calculator in Debian and then do a separate upload in Ubuntu (along with all the required Vcs merging, updating and tagging) just to add the epoch in Ubuntu. It would be a lot nicer if I could just sync the Debian package to Ubuntu. So is it appropriate to bump an epoch in Debian to match an important downstream's epoch? [1] Current example of the hack: https://salsa.debian.org/fonts-team/fonts-ubuntu/blob/debian/unstable/debian/rules Thanks, Jeremy Bicha
Re: Let's start salvaging packages!
On Wed, 26 Sep 2018 07:45:45 +0200, Tobias Frost wrote: > The yesteday uploaded Developer's Reference has now got a chapter > about "Package Salvaging". [1] That's excellent news. Thanks Tobi for driving this inititiative! Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: Fleetwood Mac: As Long As You Follow signature.asc Description: Digital Signature
Behaviour inconsistency between apt and aptitude (on nvidia-related packages)
Dear all,
I just encountered some weird problem around installing bumblebee-nvidia using
apt and aptitude on Debian Unstable. Here's what I did:
$ sudo apt purge '*nvidia*'
$ sudo apt autoremove --purge
$ sudo apt update
$ dpkg --print-architecture
amd64
$ dpkg --print-foreign-architectures
i386
For apt:
$ sudo apt install bumblebee-nvidia primus- nvidia-driver-
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'primus' is not installed, so not removed
Package 'nvidia-driver' is not installed, so not removed
The following additional packages will be installed:
bbswitch-dkms bumblebee dkms glx-alternative-mesa glx-alternative-nvidia
glx-diversions libegl1-nvidia-legacy-340xx libgl1-nvidia-legacy-340xx-glx
libnvidia-legacy-340xx-eglcore libnvidia-legacy-340xx-glcore libnvidia-
legacy-340xx-ml1 linux-headers-amd64 nvidia-installer-cleanup nvidia-kernel-
common:i386
nvidia-legacy-340xx-alternative nvidia-legacy-340xx-driver nvidia-
legacy-340xx-driver-bin nvidia-legacy-340xx-driver-libs nvidia-legacy-340xx-
kernel-dkms
nvidia-legacy-340xx-kernel-support:i386 nvidia-legacy-340xx-vdpau-driver
nvidia-modprobe:i386 nvidia-support update-glx xserver-xorg-video-nvidia-
legacy-340xx
Suggested packages:
python3-apport menu nvidia-driver
Recommended packages:
virtualgl | primus nvidia-settings-legacy-340xx nvidia-persistenced nvidia-
legacy-340xx-driver-libs-i386 libgles1-nvidia-legacy-340xx libgles2-nvidia-
legacy-340xx
libnvidia-legacy-340xx-cfg1
The following NEW packages will be installed:
bbswitch-dkms bumblebee bumblebee-nvidia dkms glx-alternative-mesa glx-
alternative-nvidia glx-diversions libegl1-nvidia-legacy-340xx libgl1-nvidia-
legacy-340xx-glx
libnvidia-legacy-340xx-eglcore libnvidia-legacy-340xx-glcore libnvidia-
legacy-340xx-ml1 linux-headers-amd64 nvidia-installer-cleanup nvidia-kernel-
common:i386
nvidia-legacy-340xx-alternative nvidia-legacy-340xx-driver nvidia-
legacy-340xx-driver-bin nvidia-legacy-340xx-driver-libs nvidia-legacy-340xx-
kernel-dkms
nvidia-legacy-340xx-kernel-support:i386 nvidia-legacy-340xx-vdpau-driver
nvidia-modprobe:i386 nvidia-support update-glx xserver-xorg-video-nvidia-
legacy-340xx
0 upgraded, 26 newly installed, 0 to remove and 0 not upgraded.
Need to get 23.7 MB of archives.
After this operation, 137 MB of additional disk space will be used.
Do you want to continue? [Y/n]
And for aptitude:
$ sudo aptitude install bumblebee-nvidia primus- nvidia-driver-
Package primus is not installed, so it will not be removed
Package nvidia-driver is not installed, so it will not be removed
Package primus is not installed, so it will not be removed
Package nvidia-driver is not installed, so it will not be removed
The following NEW packages will be installed:
bbswitch-dkms{a} bumblebee{a} bumblebee-nvidia dkms{a} glx-alternative-
mesa{a} glx-alternative-nvidia{a} glx-diversions{a} libegl-mesa0:i386{a}
libegl-nvidia0{a}
libegl-nvidia0:i386{a} libegl1:i386{a} libgbm1:i386{a} libgl1-nvidia-glvnd-
glx{a} libgl1-nvidia-glvnd-glx:i386{a} libgles-nvidia2:i386{a}
libgles2:i386{a}
libglx-nvidia0{a} libglx-nvidia0:i386{a} libnvidia-cfg1:i386{a} libnvidia-
egl-wayland1{a} libnvidia-egl-wayland1:i386{a} libnvidia-eglcore{a}
libnvidia-eglcore:i386{a} libnvidia-glcore{a} libnvidia-glcore:i386{a}
libnvidia-ml1{a} libopengl0:i386{a} libvulkan1:i386{a} libwayland-
client0:i386{a}
libwayland-server0:i386{a} libxnvctrl0{a} linux-headers-amd64{a} nvidia-
alternative{a} nvidia-driver-libs:i386{a} nvidia-driver-libs-i386:i386{a}
nvidia-egl-common{a} nvidia-egl-icd:i386{a} nvidia-egl-wayland-common{a}
nvidia-egl-wayland-icd:i386{a} nvidia-installer-cleanup{a} nvidia-kernel-
common{a}
nvidia-kernel-dkms{a} nvidia-kernel-support{a} nvidia-legacy-check{a}
nvidia-modprobe{a} nvidia-settings{a} nvidia-support{a} nvidia-vdpau-driver{a}
nvidia-vulkan-common{a} nvidia-vulkan-icd{a} nvidia-vulkan-icd:i386{a}
update-glx{a} xserver-xorg-video-nvidia{a}
The following packages are RECOMMENDED but will NOT be installed:
libcuda1 nvidia-driver primus
0 packages upgraded, 53 newly installed, 0 to remove and 0 not upgraded.
Need to get 49.1 MB of archives. After unpacking 201 MB will be used.
Do you want to continue? [Y/n/?]
(I know that bumblebee is not meant to be used as above, but we are talking
about dependency handling so it's just an example)
---
As you can see, the behaviour of apt is expected (choosing an dependency from
alternative list when a dependency "nvidia-driver" is not to be installed) but
aptitude is giving a weird answer: it just ignored the hard dependnecy that
"bumblebee-nvidia depends on nvidia-driver | ... " but downgraded this
dependency to "RECOMMENDED but will NOT be installed". That is really strange
since aptitude seems to have ignored a hard dependency.
This scenario is a little bit complicated and might not only be related to
either aptitude or nvidia-related packages so
Bug#909670: ITP: gnome-remote-desktop -- Remote desktop daemon for GNOME using Pipewire
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: jbi...@debian.org Package Name: gnome-remote-desktop Version: 0.1.6 Upstream Authors: Jonas Ådahl, Red Hat License : GPL-2+ Programming Lang: C Homepage: https://wiki.gnome.org/Projects/Mutter/RemoteDesktop Description: Remote desktop daemon for GNOME using PipeWire This daemon enables GNOME to offer remote desktop sharing using VNC with PipeWire. It supports both GNOME on X and GNOME on Wayland. Remote sharing can be enabled and managed in the GNOME Settings app. . This feature will not work on Ubuntu until mutter is recompiled with the remote desktop option enabled. Other Info -- The Debian GNOME team intends to maintain this package. If testing goes well, we would like to install this package by default in Debian GNOME for Buster since we currently default to Wayland. Otherwise, at least it will be available as an option for people using Buster. Packaging is at https://salsa.debian.org/gnome-team/gnome-remote-desktop Thanks, Jeremy Bicha
Re: epoch bump request for gnome-calculator
Quoting Jeremy Bicha (2018-09-26 15:47:38) > Emailing both debian-devel and the Debian GNOME mailing list. > > I am requesting project approval for me to upload gnome-calculator > with an epoch. > > Five years ago, gcalctool 6.4 was renamed to gnome-calculator and > renumbered to 3.8. This seemed like a clear case for an epoch since > this was a permanent change in the version numbering scheme. > > I made this change in the Debian VCS and uploaded it to Ubuntu. At the > time I did not have upload rights to Debian and Ubuntu has deadlines. > > A month later, a Debian GNOME team member recognized that we could use > a dh_gencontrol hack [1] to only add the epoch to the gcalctool > transitional package and we didn't need an epoch for gnome-calculator. > Similarly, we could have used this hack for many of the gnome-games > packages when they were split into separate source packages but we > didn't because we uploaded them before we made this change. (The > version numbering didn't change but gnome-games had an epoch we didn't > need to carry to the new packages.) > > More recently, I have worked to reduce the difference between Debian > and Ubuntu packaging for many GNOME packages. It gets very tedious to > need to upload gnome-calculator in Debian and then do a separate > upload in Ubuntu (along with all the required Vcs merging, updating > and tagging) just to add the epoch in Ubuntu. It would be a lot nicer > if I could just sync the Debian package to Ubuntu. > > So is it appropriate to bump an epoch in Debian to match an important > downstream's epoch? Please no: Don't adopt in Debian mistakes done in downstream distros. - 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: Let's start salvaging packages!
Gregor wrote: > > The yesteday uploaded Developer's Reference has now got a chapter > > about "Package Salvaging". [1] > > That's excellent news. Thanks Tobi for driving this inititiative! Indeed — congratulations and thank you for seeing this all the way through. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Let's start salvaging packages!
Tobias Frost wrote on 26/09/2018: > The yesteday uploaded Developer's Reference has now got a chapter > about "Package Salvaging". Thanks Tobias for this work, I truly think Debian will benefit a lot from it. I already filed an ITS: #909663. The Developer's Reference was smooth to follow, I just have a couple of impressions to share: 1. Writing the bug was a bit strange, as it was not clear to me whom was it addressed to. Ideally its objective is to warn the current maintainer about the ITS, but it feels more like writing to debian-devel to justify the salvaging. In my case it also felt like writing to whoever I will ask to sponsor the salvaging upload. I ended up writing it in a rather impersonal form. 2. The Reference says "you must inform all maintainers, uploaders and if applicable the packaging team explicitly by adding them to X-Debbugs-CC". I followed this literally and added an X-Debbugs-CC to the maintainer's address, but this is probably not necessary as the maintainer already gets a copy of the email. Cheers, Paride signature.asc Description: OpenPGP digital signature
Bug#909675: ITP: equinox-p2 -- Provisioning technology for OSGi-based applications
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: equinox-p2 Version : 4.7.3 Upstream Author : Eclipse Foundation, Inc. * URL : http://www.eclipse.org/equinox/p2/ * License : EPL-1.0 Programming Lang: Java Description : Provisioning technology for OSGi-based applications The Eclipse Equinox p2 project focuses on provisioning technology for OSGi-based applications. Although p2 has specific support for installing Eclipse and Equinox-based applications, it includes a general-purpose provisioning infrastructure that can be used as the basis for provisioning solutions for a wide variety of software applications. This package will be maintained by the Java Team. It's required to transition away from the old src:eclipse package.
Re: Behaviour inconsistency between apt and aptitude (on nvidia-related packages)
On 2018-09-26 10:38 -0400, Boyuan Yang wrote:
> I just encountered some weird problem around installing bumblebee-nvidia
> using
> apt and aptitude on Debian Unstable. Here's what I did:
>
> $ sudo apt purge '*nvidia*'
> $ sudo apt autoremove --purge
> $ sudo apt update
> $ dpkg --print-architecture
> amd64
> $ dpkg --print-foreign-architectures
> i386
>
> For apt:
>
> $ sudo apt install bumblebee-nvidia primus- nvidia-driver-
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package 'primus' is not installed, so not removed
> Package 'nvidia-driver' is not installed, so not removed
> The following additional packages will be installed:
> bbswitch-dkms bumblebee dkms glx-alternative-mesa glx-alternative-nvidia
> glx-diversions libegl1-nvidia-legacy-340xx libgl1-nvidia-legacy-340xx-glx
> libnvidia-legacy-340xx-eglcore libnvidia-legacy-340xx-glcore libnvidia-
> legacy-340xx-ml1 linux-headers-amd64 nvidia-installer-cleanup nvidia-kernel-
> common:i386
> nvidia-legacy-340xx-alternative nvidia-legacy-340xx-driver nvidia-
> legacy-340xx-driver-bin nvidia-legacy-340xx-driver-libs nvidia-legacy-340xx-
> kernel-dkms
> nvidia-legacy-340xx-kernel-support:i386 nvidia-legacy-340xx-vdpau-driver
> nvidia-modprobe:i386 nvidia-support update-glx xserver-xorg-video-nvidia-
> legacy-340xx
> Suggested packages:
> python3-apport menu nvidia-driver
> Recommended packages:
> virtualgl | primus nvidia-settings-legacy-340xx nvidia-persistenced nvidia-
> legacy-340xx-driver-libs-i386 libgles1-nvidia-legacy-340xx libgles2-nvidia-
> legacy-340xx
> libnvidia-legacy-340xx-cfg1
> The following NEW packages will be installed:
> bbswitch-dkms bumblebee bumblebee-nvidia dkms glx-alternative-mesa glx-
> alternative-nvidia glx-diversions libegl1-nvidia-legacy-340xx libgl1-nvidia-
> legacy-340xx-glx
> libnvidia-legacy-340xx-eglcore libnvidia-legacy-340xx-glcore libnvidia-
> legacy-340xx-ml1 linux-headers-amd64 nvidia-installer-cleanup nvidia-kernel-
> common:i386
> nvidia-legacy-340xx-alternative nvidia-legacy-340xx-driver nvidia-
> legacy-340xx-driver-bin nvidia-legacy-340xx-driver-libs nvidia-legacy-340xx-
> kernel-dkms
> nvidia-legacy-340xx-kernel-support:i386 nvidia-legacy-340xx-vdpau-driver
> nvidia-modprobe:i386 nvidia-support update-glx xserver-xorg-video-nvidia-
> legacy-340xx
> 0 upgraded, 26 newly installed, 0 to remove and 0 not upgraded.
> Need to get 23.7 MB of archives.
> After this operation, 137 MB of additional disk space will be used.
> Do you want to continue? [Y/n]
>
> And for aptitude:
>
> $ sudo aptitude install bumblebee-nvidia primus- nvidia-driver-
> Package primus is not installed, so it will not be removed
> Package nvidia-driver is not installed, so it will not be removed
> Package primus is not installed, so it will not be removed
> Package nvidia-driver is not installed, so it will not be removed
> The following NEW packages will be installed:
> bbswitch-dkms{a} bumblebee{a} bumblebee-nvidia dkms{a} glx-alternative-
> mesa{a} glx-alternative-nvidia{a} glx-diversions{a} libegl-mesa0:i386{a}
> libegl-nvidia0{a}
> libegl-nvidia0:i386{a} libegl1:i386{a} libgbm1:i386{a} libgl1-nvidia-glvnd-
> glx{a} libgl1-nvidia-glvnd-glx:i386{a} libgles-nvidia2:i386{a}
> libgles2:i386{a}
> libglx-nvidia0{a} libglx-nvidia0:i386{a} libnvidia-cfg1:i386{a} libnvidia-
> egl-wayland1{a} libnvidia-egl-wayland1:i386{a} libnvidia-eglcore{a}
> libnvidia-eglcore:i386{a} libnvidia-glcore{a} libnvidia-glcore:i386{a}
> libnvidia-ml1{a} libopengl0:i386{a} libvulkan1:i386{a} libwayland-
> client0:i386{a}
> libwayland-server0:i386{a} libxnvctrl0{a} linux-headers-amd64{a} nvidia-
> alternative{a} nvidia-driver-libs:i386{a} nvidia-driver-libs-i386:i386{a}
> nvidia-egl-common{a} nvidia-egl-icd:i386{a} nvidia-egl-wayland-common{a}
> nvidia-egl-wayland-icd:i386{a} nvidia-installer-cleanup{a} nvidia-kernel-
> common{a}
> nvidia-kernel-dkms{a} nvidia-kernel-support{a} nvidia-legacy-check{a}
> nvidia-modprobe{a} nvidia-settings{a} nvidia-support{a}
> nvidia-vdpau-driver{a}
> nvidia-vulkan-common{a} nvidia-vulkan-icd{a} nvidia-vulkan-icd:i386{a}
> update-glx{a} xserver-xorg-video-nvidia{a}
> The following packages are RECOMMENDED but will NOT be installed:
> libcuda1 nvidia-driver primus
> 0 packages upgraded, 53 newly installed, 0 to remove and 0 not upgraded.
> Need to get 49.1 MB of archives. After unpacking 201 MB will be used.
> Do you want to continue? [Y/n/?]
>
> As you can see, the behaviour of apt is expected (choosing an dependency from
> alternative list when a dependency "nvidia-driver" is not to be installed)
> but
> aptitude is giving a weird answer: it just ignored the hard dependnecy that
> "bumblebee-nvidia depends on nvidia-driver | ... " but downgraded this
> dependency to "RECOMMENDED but will NOT be installed". That is really strange
> since aptitude seems to have ignored a hard dependency.
It didn't, it just chose t
Re: installation-guide is marked for autoremoval from testing
Hi, Debian testing autoremoval watch wrote: > installation-guide 20180603 is marked for autoremoval from testing on > 2018-10-11 > > It is affected by these RC bugs: > 898665: installation-guide: [installation-guide] change "Alioth" and "svn" to > "Salsa" and "git" we got this note today. However, the mentioned bug #898665 has been closed with the latest upload 3 days ago. What can be done about this? Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Re: installation-guide is marked for autoremoval from testing
Am 26.09.2018 um 19:50 schrieb Holger Wansing: > Hi, > > Debian testing autoremoval watch wrote: >> installation-guide 20180603 is marked for autoremoval from testing on >> 2018-10-11 >> >> It is affected by these RC bugs: >> 898665: installation-guide: [installation-guide] change "Alioth" and "svn" >> to "Salsa" and "git" > > we got this note today. > > However, the mentioned bug #898665 has been closed with the latest upload > 3 days ago. > > > What can be done about this? > ttbomk there were some debbugs related issues the last couple of days which should be solved by now. Don should know more. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: installation-guide is marked for autoremoval from testing
Michael Biebl, le mer. 26 sept. 2018 19:53:22 +0200, a ecrit: > Am 26.09.2018 um 19:50 schrieb Holger Wansing: > > Debian testing autoremoval watch wrote: > >> installation-guide 20180603 is marked for autoremoval from testing on > >> 2018-10-11 > >> > >> It is affected by these RC bugs: > >> 898665: installation-guide: [installation-guide] change "Alioth" and "svn" > >> to "Salsa" and "git" > > > > we got this note today. > > > > However, the mentioned bug #898665 has been closed with the latest upload > > 3 days ago. > > > > What can be done about this? > > ttbomk there were some debbugs related issues the last couple of days > which should be solved by now. Actually the real issue is that the 20180603 version of installation-guide migrated to testing while it shouldn't have. It's that version which is marked as to be removed, so no worry. At least, https://packages.qa.debian.org/i/installation-guide.html now says Updating installation-guide fixes old bugs: #898665 So I don't think we have anything to do about it. Samuel
Re: Re: Bug#906183: Dependency change and upgrade
Hi Russ, Just checked it. Yes, apt upgrade does upgrade successfully. Thank you so much. My whole question is mute now. Regards Mohan
Re: Let's start salvaging packages!
Tobias Frost: > Hallo everyone, > > The yesteday uploaded Developer's Reference has now got a chapter > about "Package Salvaging". [1] > > So, package salvaging is now implemented and ready to be used, > and whenever you find some package in need, you can now consider to > salvage it for the benefit of Debian and our users. > > [1] > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging I'd like to give my thanks for your work on this. I know it wasn't easy, and it's been needed for a long time. I've reviewed the resulting document sections and it looks great to me. Thanks very much. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Re: Let's start salvaging packages!
Let's salvaging developers. On Wed, Sep 26, 2018 at 9:14 PM Chris Knadle wrote: > > Tobias Frost: > > Hallo everyone, > > > > The yesteday uploaded Developer's Reference has now got a chapter > > about "Package Salvaging". [1] > > > > So, package salvaging is now implemented and ready to be used, > > and whenever you find some package in need, you can now consider to > > salvage it for the benefit of Debian and our users. > > > > [1] > > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging > > I'd like to give my thanks for your work on this. I know it wasn't easy, and > it's been needed for a long time. I've reviewed the resulting document > sections > and it looks great to me. > Thanks very much. > >-- Chris > > -- > Chris Knadle > chris.kna...@coredump.us >
Re: Let's start salvaging packages!
Hi all Seriously, this is the wrong approach. I am the upstream of a package. I have dependencies but am unsure about how to monetize my software or fund my dependencies. Might be I decide once to stop work full-time on it. Just because someone feels uncomfortable about the situation of a particular package, you can't take it away of his guidance. Because it is wrong. And it doesn't solve any problem. Rather introduces a more driven situation. Having 2 or even more upstream developers. Bests, Joël On Wed, Sep 26, 2018 at 9:23 PM Joël Krähemann wrote: > > Let's salvaging developers. > > On Wed, Sep 26, 2018 at 9:14 PM Chris Knadle wrote: > > > > Tobias Frost: > > > Hallo everyone, > > > > > > The yesteday uploaded Developer's Reference has now got a chapter > > > about "Package Salvaging". [1] > > > > > > So, package salvaging is now implemented and ready to be used, > > > and whenever you find some package in need, you can now consider to > > > salvage it for the benefit of Debian and our users. > > > > > > [1] > > > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#package-salvaging > > > > I'd like to give my thanks for your work on this. I know it wasn't easy, > > and > > it's been needed for a long time. I've reviewed the resulting document > > sections > > and it looks great to me. > > Thanks very much. > > > >-- Chris > > > > -- > > Chris Knadle > > chris.kna...@coredump.us > >
Re: epoch bump request for gnome-calculator
Hey Jonas On 26/09/2018 16:59, Jonas Smedegaard wrote: >> More recently, I have worked to reduce the difference between Debian >> and Ubuntu packaging for many GNOME packages. It gets very tedious to >> need to upload gnome-calculator in Debian and then do a separate >> upload in Ubuntu (along with all the required Vcs merging, updating >> and tagging) just to add the epoch in Ubuntu. It would be a lot nicer >> if I could just sync the Debian package to Ubuntu. >> >> So is it appropriate to bump an epoch in Debian to match an important >> downstream's epoch? > > Please no: Don't adopt in Debian mistakes done in downstream distros. I appreciate where your sentiment regarding this issue comes from, but I think it comes across as a bit snide. Jeremy has pulled a lot of weight making GNOME a first class citizen in Debian, and I think you should rather look at it from the perspective that a DD is spending a lot of time on duplicate work that effectively ends up being busy work. No one like epoch bumps but I know Jeremy wouldn't suggest anything without spending a considerable amount of time putting thought in to it. Personally I think you should reconsider before shooting off a 'no' so quickly. And on that note I also agree with you that Debian shouldn't pay for downstream mistakes, but this is clearly a bit different and a bit more than that. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Let's start salvaging packages!
Joël Krähemann: > Hi all > > Seriously, this is the wrong approach. > > I am the upstream of a package. I have dependencies but am unsure > about how to monetize my software or fund my dependencies. > > Might be I decide once to stop work full-time on it. Just because > someone feels uncomfortable about the situation of a particular package, you > can't take it away of > his guidance. Because it > is wrong. > > And it doesn't solve any problem. Rather introduces a more driven > situation. Having 2 or even > more upstream developers. > > Bests, > Joël This isn't about upstream ownership of software, this is about salvaging the Debian package specifically, where the package has been neglected for a long time and whose maintainer isn't responsive to bug reports or email contact, and allowing for a process for another maintainer to fix up the package. Without some standard process for forward progress, the package remains in a broken state and there are a lot of situations in which NMUs (Non-Maintainer Uploads) aren't appropriate. I've been in the situation of relying on software in Debian that was broken, and before this process there wasn't a known path of how to deal with that. Matter of fact that's how I started getting into Debian development in the first place. It is unfortunately not uncommon to find a package [un|under]maintained such that the pacakge in Debian needs salvaging. I hope this helps clarify. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: OpenPGP digital signature
Re: epoch bump request for gnome-calculator
Am 26.09.2018 um 15:47 schrieb Jeremy Bicha: > So is it appropriate to bump an epoch in Debian to match an important > downstream's epoch? I don't think it is. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: epoch bump request for gnome-calculator
Hi Jonathan, and Jeremy and others, Quoting Jonathan Carter (2018-09-26 20:45:13) > On 26/09/2018 16:59, Jonas Smedegaard wrote: >>> More recently, I have worked to reduce the difference between Debian >>> and Ubuntu packaging for many GNOME packages. It gets very tedious >>> to need to upload gnome-calculator in Debian and then do a separate >>> upload in Ubuntu (along with all the required Vcs merging, updating >>> and tagging) just to add the epoch in Ubuntu. It would be a lot >>> nicer if I could just sync the Debian package to Ubuntu. >>> >>> So is it appropriate to bump an epoch in Debian to match an >>> important downstream's epoch? >> >> Please no: Don't adopt in Debian mistakes done in downstream distros. > > I appreciate where your sentiment regarding this issue comes from, but > I think it comes across as a bit snide. > > Jeremy has pulled a lot of weight making GNOME a first class citizen > in Debian, and I think you should rather look at it from the > perspective that a DD is spending a lot of time on duplicate work that > effectively ends up being busy work. > > No one like epoch bumps but I know Jeremy wouldn't suggest anything > without spending a considerable amount of time putting thought in to > it. > > Personally I think you should reconsider before shooting off a 'no' so > quickly. And on that note I also agree with you that Debian shouldn't > pay for downstream mistakes, but this is clearly a bit different and a > bit more than that. I apologize if coming across as snide. Or rude or insensitive. I have no doubt that Jeremy has thought through his question and the options available to him in this matter, and that Jeremy has done a great deal of good work for Debian and is likely to continue to do so. My response was not intended as some kind of personal attack on Jeremy, it was solely uttered out of concern for Debian. Please do believe and respect that I have _also_ given this matter quite some thought. Regards, - 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
Question regarding patching in 4.9 kernel
Hi, I want the following patch to be back ported to 4.9 kernel. Can you please let me know if it can be back ported to 4.9 kernel? https://github.com/torvalds/linux/commit/63a6fff353d01da5a22b72670c434bf12fa0e3b8 Thanks
Re: epoch bump request for gnome-calculator
On Wed, Sep 26, 2018 at 9:48 PM Jeremy Bicha wrote: > A month later, a Debian GNOME team member recognized that we could use > a dh_gencontrol hack [1] to only add the epoch to the gcalctool > transitional package and we didn't need an epoch for gnome-calculator. I wouldn't characterise this as a hack, it is a legitimate way to do things. > More recently, I have worked to reduce the difference between Debian > and Ubuntu packaging for many GNOME packages. FTR, this is currently this set of changes: https://patches.ubuntu.com/g/gnome-calculator/gnome-calculator_1:3.30.0-1ubuntu1.patch > So is it appropriate to bump an epoch in Debian to match an important > downstream's epoch? An alternative might be for Launchpad to allow whitelisted downgrades of source packages (dropping the epoch) (zero idea how feasible that is) and then a dpkg-vendor conditional in debian/rules to re-add the epoch to the binary packages when they are being built for Ubuntu. This would result in zero change to Debian binary packages, Ubuntu binary packages to continue to use the epoch, the source package to be in sync and require zero busywork in Ubuntu and everyone should be happy (except maybe the Launchpad team). -- bye, pabs https://wiki.debian.org/PaulWise
Re: Question regarding patching in 4.9 kernel
[Note Reply-to: debian-kernel.] On Wed, 2018-09-26 at 18:00 +, Harish Venkatraman wrote: > Hi, > > I want the following patch to be back ported to 4.9 kernel. Can you > please let me know if it can be back ported to 4.9 kernel? > > https://github.com/torvalds/linux/commit/63a6fff353d01da5a22b72670c434bf12fa0e3b8 I assume you're talking about Linux 4.9 as used in Debian 9 "stretch". Debian doesn't normally add features to stable releases, so I don't see why would we do this. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Re: epoch bump request for gnome-calculator
On Wed, Sep 26, 2018 at 9:33 PM Paul Wise wrote: > FTR, this is currently this set of changes: > > https://patches.ubuntu.com/g/gnome-calculator/gnome-calculator_1:3.30.0-1ubuntu1.patch Yes, I felt my email was getting a bit long. Ubuntu's gnome-calculator now has some patches that depend on proposed gnome-shell search provider improvements. There's a bit of a backlog for Ubuntu's gnome-shell patches getting reviewed in GNOME. So there is a temporary diff but there was no diff except for the epoch for the 18.04 LTS release. > An alternative might be for Launchpad to allow whitelisted downgrades I appreciate your thinking of possible solutions, but my understanding is that Canonical isn't investing in any more Launchpad work than is necessary. And it's rare for anyone else to work on Launchpad. Thanks, Jeremy Bicha
Re: epoch bump request for gnome-calculator
Hi Jeremy, My comments below for what it's worth. You should likely not take anything I say too seriously, but maybe I happen to mention something that can be food for thought. On Wed, Sep 26, 2018 at 09:47:38AM -0400, Jeremy Bicha wrote: > Emailing both debian-devel and the Debian GNOME mailing list. > > I am requesting project approval for me to upload gnome-calculator > with an epoch. > > Five years ago, gcalctool 6.4 was renamed to gnome-calculator and > renumbered to 3.8. This seemed like a clear case for an epoch since > this was a permanent change in the version numbering scheme. For me, wherever a (source and binary) package is removed it's a clear case that it's an opportunity to *get rid* of epochs. Upstream renaming things are a rare opportunity and should be utilized! > > I made this change in the Debian VCS and uploaded it to Ubuntu. At the > time I did not have upload rights to Debian and Ubuntu has deadlines. > > A month later, a Debian GNOME team member recognized that we could use > a dh_gencontrol hack [1] to only add the epoch to the gcalctool > transitional package and we didn't need an epoch for gnome-calculator. > Similarly, we could have used this hack for many of the gnome-games > packages when they were split into separate source packages but we > didn't because we uploaded them before we made this change. (The > version numbering didn't change but gnome-games had an epoch we didn't > need to carry to the new packages.) I feel like I was probably the guilty person here. Possibly having higher-than-average dislike for epochs and also being clueless on ubuntu deadlines. I feel like rushing an epoch bump in because of a deadline is a bad idea, which you are probably well aware of as of now. (And yes, there where probably more cases this should have been used but once uploaded the window of opportunity to eliminate the epochs are gone and we have to wait, pray and hope that upstream renames things again some time in the future.) Also Debhelper commands are overridable by design and their individual arguments are documented in their separate manual pages. This should be leveraged when ever it's the appropriate thing to do (and avoided when it's not). > > More recently, I have worked to reduce the difference between Debian > and Ubuntu packaging for many GNOME packages. It gets very tedious to > need to upload gnome-calculator in Debian and then do a separate > upload in Ubuntu (along with all the required Vcs merging, updating > and tagging) just to add the epoch in Ubuntu. It would be a lot nicer > if I could just sync the Debian package to Ubuntu. > > So is it appropriate to bump an epoch in Debian to match an important > downstream's epoch? I understand this is annoying for you to have to carry forever in ubuntu, so I'm willing to look the other way with one condition: You make sure to discuss policies on the ubuntu side to take extra care to not needlessly introduce epoch bumps which you then later come to debian to discuss because it's causing you pain in ubuntu. If you ever bump epoch in ubuntu without having done the full epoch-dance in debian and waited for it to actually be uploaded to the debian archive before you upload the epoch bump in ubuntu, then you agree to handle it for all eternity on the ubuntu side when needed. As an alternative suggestion, why isn't it possible to simply get rid of the annoying part by specifying a vendor-condition in debian/rules and apply "the hack" to all binary packages when building on ubuntu (and on transitional packages only when building on debian)? Carrying this ubuntu-specific lines in debian/rules even in debian would likely be something that people who only care for debian could more easily accept. eg. ifeq ($(DEB_VENDOR),Ubuntu) endif > > [1] Current example of the hack: > https://salsa.debian.org/fonts-team/fonts-ubuntu/blob/debian/unstable/debian/rules > > Thanks, > Jeremy Bicha > Regards, Andreas Henriksson (who hasn't mastered the art of writing short mails yet either)
