Niels Thykier:
Hi,
This is an update on the MBF for `Rules-Requires-Root: no` as the new
default.
Two weeks further down the line with another update. :)
# Qualitative updates:
* I have asked the release team to look into whether we should go ahead
with this for Trixie or wait until a
Hi,
This is an update on the MBF for `Rules-Requires-Root: no` as the new
default.
# Qualitative updates:
* The bugs have all been filed. Most where filed on Dec 7, but I had
to file 15 special cases manually, which happened Dec 14.
* A number of permission denied issues have been iden
On Mon, Oct 28, 2024 at 10:24:04AM +0100, Chris Hofstaedtler wrote:
> b) various packages already ignore s390x (gnome? others?)
WebKitGTK still builds in s390x, but the Skia graphics library does
not support big-endian machines so if the Cairo backend is ever
dropped then we probably won't be able
Hi everyone,
I am employed with IBM as a Debian maintainer for the S390x. I would like to
assume responsibility for this bundle. I previously replied to the bug below
about updating it due to OpenSSL errors.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080317
Many changes and bugs have b
On Mon, Oct 28, 2024 at 5:49 AM Marco d'Itri wrote:
>
> On Oct 28, Chris Hofstaedtler wrote:
>
> > It also appears true that IBM has an interest in s390x, but today
> I wonder if their interest could actually be just in Debian providing
> a base for the Ubuntu port (which I understand used to be
On Oct 28, Chris Hofstaedtler wrote:
> It also appears true that IBM has an interest in s390x, but today
I wonder if their interest could actually be just in Debian providing
a base for the Ubuntu port (which I understand used to be funded by
IBM).
And if this is still true now that IBM owns Re
e the cause of interest for curious people,
> in general it seems to cause more problems than we need.
I believe the latest status from porters outside Debian is that the
GTK and librsvg issues are believed to be caused by a regression in
src:pixman, and not actually the GNOME libraries' fa
Hello!
I want to draw attention to, from my point of view, open
questions/problems with the s390x architecture.
In short, it seems to me, that:
a) there are no porters left (to fix serious problems)
b) various packages already ignore s390x (gnome? others?)
c) general, including upstreams, interes
Hi,
it seems the only OpenMAX implementation got removed from unstable, and
ffmpeg drops OpenMAX support as well because that implementation was
providing the header files.
That is a bit suboptimal for me, because the VisionFive2 hardware video
encoder is also interfaced using OpenMAX IL.
is on our end. There's no metadata for archived
project status, just a convention that projects empty out their
default Git branch and replace the readme with ad hoc information
about ceasing maintenance or moving to another service. Also OpenDev
currently only hosts a few thousand projects
Hi Simon,
I think there could be a more global solution for this problem:
the vcswatch service could know about Gihub & Opendev infamous
"This project has been archived ..."
and the wontfix/upstream bug could be filed automatically to notify
the maintainers that the current upstream dropped the
: MIT
Programming Lang: Python
Description : Python library for FAA airport status data
This library facilitates access to real-time airport status data from the
Federal Aviation Administration's (FAA) NAS Status API. The FAA, an agency of
the United States Departme
On Sun, Apr 28, 2024 at 02:28:30PM +0200, Paul Gevers wrote:
> > Can you please look at libproxy<->glib-networking? libproxy excuses show
> > glib-networking tests failing, but they are working in sid.
>
> And that's not missing a versioned Depends and/or Breaks? I.e. this is a
> test only failure
Hi,
On 27-04-2024 7:52 p.m., Andrey Rakhmatullin wrote:
Can you please look at libproxy<->glib-networking? libproxy excuses show
glib-networking tests failing, but they are working in sid.
And that's not missing a versioned Depends and/or Breaks? I.e. this is a
test only failure?
Paul
Ope
On Wed, Apr 24, 2024 at 07:38:42PM +0200, Paul Gevers wrote:
> Hi,
>
> On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
> > What to do with autopkgtests that fail in testing because of problems with
> > packages in testing that are fixed in unstable, e.g. the autopkgtest for
> > speech-dispatch
Hi,
On 24-04-2024 7:42 p.m., Jérémy Lal wrote:
Inform the Release Team and we can either schedule the combination
manually, add a hint or both.
Isn't it processed automatically ? What needs manual intervention and
what doesn't ?
Well, the migration software *tries* to figure out com
Hi,
On 24-04-2024 7:38 p.m., Paul Gevers wrote:
On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
What to do with autopkgtests that fail in testing because of problems
with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
Inform the Rel
Le mer. 24 avr. 2024 à 19:39, Paul Gevers a écrit :
> Hi,
>
> On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
> > What to do with autopkgtests that fail in testing because of problems
> with
> > packages in testing that are fixed in unstable, e.g. the autopkgtest for
> > speech-dispatcher/0.1
Hi,
On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
What to do with autopkgtests that fail in testing because of problems with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
Inform the Release Team and we can either schedule the combi
On Wed, Apr 24, 2024 at 08:51:48AM +0200, Sebastian Ramacher wrote:
> If you wonder how you are able to help with the migration, here are
> some things to do:
> * Fix FTBFS bugs
> * Check the status of autopkgtests [1] and report or fix any issues
> related to failing tests.
>
through all the packages hat need to migrate.
Since the time_t bugs are now also RC in trixie, I will reraise the
severity of all time_t bugs to serious in 1 week.
If you wonder how you are able to help with the migration, here are
some things to do:
* Fix FTBFS bugs
* Check the status of
Hi Andreas,
please stop reopening the time_t bugs where transitions are staged in
experimental. When we eventually start those transitions, they do not
need to change the package name again as they will enter unstable with a
new SONAME and built with the 64 bit time_t ABI.
Cheers
--
Sebastian Ra
Lists updated to omit packages not in testing:
On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include pack
On 18.04.24 21:22, Sebastian Ramacher wrote:
Hi,
as the progress on the t64 transition is slowing down, I want to give an
overview of some of the remaining blockers that we need to tackle to get
it unstuck. I tried to identify some clusters of issues, but there might
be other classes of issues.
All missing bugs about wrong deps are now filed.
--
WBR, wRAR
signature.asc
Description: PGP signature
Hi
thanks for checking all the packages and filing bugs!
On 2024-04-20 00:43:30 +0500, Andrey Rakhmatullin wrote:
> On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> > Let's start with the first category. Those are packages that could be
> > binNMUed, but there are issues that
Hi Andreas
On 2024-04-19 10:49:15 +0200, Andreas Tille wrote:
> I've spotted these Debian Med packages.
>
> > gentle
gentle required a rebuild for wxwidgets3.2 on mips64el. Done
> > jellyfish
The t64 changes were reverted. crac needs to rebuilt for this change so
that libjellyfish-2.0-2t64 can
On 2024-04-19 10:34:45 +0200, Simon Josefsson wrote:
> Sebastian Ramacher writes:
>
> > Hi,
> >
> > as the progress on the t64 transition is slowing down, I want to give an
> > overview of some of the remaining blockers that we need to tackle to get
> > it unstuck. I tried to identify some cluste
On Thu, Apr 18, 2024 at 09:22:02PM +0200, Sebastian Ramacher wrote:
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
> * are BD-Uninstallabe,
> * FTBFS b
Hi Sebastian,
Andreas Tille, on 2024-04-19:
> I've spotted these Debian Med packages.
[…]
> Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher:
[…]
> > jellyfish
> > quorum
[…]
> No idea how we can help here. Please let us know if we can do
> something.
About these two packages,
es
Upstream is working on bug #1067271.
> vg
This package is in a bad state in any case and we are aware of this.
However, could you explain in how far is this affecting t64 transition
since 32bit architectures are excluded?
> If you maintain any of the packages above, please check their
Hello,
On Thu, 2024-04-18 at 21:22 +0200, Sebastian Ramacher wrote:
> Finally, packages that need rebuilds but currently have open FTBFS (RC +
> ftbfs tag) bugs:
> (...)
> virtualjaguar
I already have a tentative patch and will fix the package within the next
days. I am also preparing to fix two
Sebastian Ramacher writes:
> Hi,
>
> as the progress on the t64 transition is slowing down, I want to give an
> overview of some of the remaining blockers that we need to tackle to get
> it unstuck. I tried to identify some clusters of issues, but there might
> be other classes of issues.
Thanks
On 2024-04-19 06:02:03 +0200, Andreas Metzler wrote:
> On 2024-04-18 Sebastian Ramacher wrote:
> [...]
> > Let's start with the first category. Those are packages that could be
> > binNMUed, but there are issues that make those rebuilds not have the
> > desired effect. This list include packages t
On 2024-04-18 Sebastian Ramacher wrote:
[...]
> Let's start with the first category. Those are packages that could be
> binNMUed, but there are issues that make those rebuilds not have the
> desired effect. This list include packages that
> * are BD-Uninstallabe,
> * FTBFS but with out ftbfs-tag
were
already removed from testing are also on these lists.
If you maintain any of the packages above, please check their status and
help get them fixed. Any help in filing bugs, fixing packages,
requesting removals, etc. is appreciated so that we can look into
unblocking the whole stack and migrate
/frameworks/kstatusnotifieritem
* License : LGPL, CC0
Programming Lang: C++
Description : Implementation of Status Notifier Items
KStatusNotifierItem provides an implementation of Status Notifier Items.
Package will be maintained within the Debian Qt/KDE team.
Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar
X-Debbugs-Cc: debian-devel@lists.debian.org, kd8...@gmail.com
* Package name: python-grpcio-status
Version : 1.62.1
Upstream Contact: The gRPC Authors
* URL : https://github.com/OctopusAI/grpcio-status
On Tue, 22 Aug 2023 at 10:21, Helmut Grohne wrote:
> Let me also put this into numbers. Across all suites, we have around
> 2200 binary packages shipping files in aliased locations. If you
> disregard systemd units, we're left with 1030 packages. In other words,
> more than half of the binary pack
Control: forwarded -1
https://salsa.debian.org/debian/debhelper/-/merge_requests/108
Control: tags -1 + patch
On Sun, Aug 20, 2023 at 11:19:56PM +0200, Michael Biebl wrote:
> Related to that:
> dh_installsystemd (and the old, deprecated dh_systemd_enable) currently only
> consider systemd unit fi
Am 19.08.23 um 23:14 schrieb Helmut Grohne:
## dh_usrmerge
I intend to add a new tool dh_usrmerge to debhelper (not yet
implemented). Its purpose is performing the path canonicalization in
binary packages. As long as the moratorium is in effect, this helper
must not be used. It shall be possibl
Hi Helmut,
On 19-08-2023 23:14, Helmut Grohne wrote:
I recognize that this is quite a non-standard way to ask for a MBF. Does
anyone object to me doing it in this way?
I recall I said this before, but just in case. In my opinion (with my
Release Team member hat on, but not on behalf of the t
Hi,
Yeah, I know we have too many /usr-merge discussions. Still, there is
reason to continue posting. My last summary/status was
https://lists.debian.org/20230712133438.ga935...@subdivi.de from July
12th and I'm giving an update of what happened since then here and
explain how I want to
Package: wnpp
Severity: wishlist
Owner: MouseZhang
X-Debbugs-Cc: debian-devel@lists.debian.org, sendbypyt...@foxmail.com
* Package name: kylin-status-manager
Version : 3.22.0.0-1
Upstream Contact: Kylin Team
* URL : https://gitee.com/openkylin/kylin-status-manager
gt; 收件人: "debian-devel@lists.debian.org" ,
> "sangm...@loongson.cn" , "Santiago Vila"
> , "张 宁" ,
> "zhangdan...@loongson.cn"
> 抄送:
> 主题: 回复: rebootstrap status update for Loongarch
>
> Hi, All
>
> I have updated my
zhangn1985/rebootstrap
发件人: Paul Wise
已发送: 2022 年 11 月 4 日 星期五 2:45
收件人: Zhang Ning; debian-devel@lists.debian.org; sangm...@loongson.cn; Santiago
Vila
主题: Re: rebootstrap status update for Loongarch
On Thu, 2022-11-03 at 18:45 +0800,
On Thu, 2022-11-03 at 18:45 +0800, Zhang Ning wrote:
> 7, m4, diffutils: need help, I don't know where is correct
> upstream[1][2], the patch[3][4] is for generated files, but Debian
> source has these files, thus how can I submit these patch to Debian
> source? these two packages don't have VCS.
On Thu, Nov 03, 2022 at 12:31:10PM +0100, Johannes Schauer Marin Rodrigues
wrote:
> Quoting Zhang Ning (2022-11-03 11:45:17)
> > 6, gcc, binutils: need help, I don't know how to submit a patch to Debian
> > toolchain-team, don't accept a poll request.
> >
> > 7, m4, diffutils: need help, I don't
Quoting Zhang Ning (2022-11-03 11:45:17)
> 6, gcc, binutils: need help, I don't know how to submit a patch to Debian
> toolchain-team, don't accept a poll request.
>
> 7, m4, diffutils: need help, I don't know where is correct upstream[1][2],
> the patch[3][4] is for generated files, but Debian
Hi, Helmut
as you mentioned, missing upstream status, I want to update below, and
my fork[0] is updated.
another purpose of this email is asking for help.
status update:
1, Linux: I will send patch to debian-kernel once dpkg name is settled.
2, glibc: https://salsa.debian.org/glibc-team/glibc
Hi, Helmut
While dpkg name for Loongarch is still under discussion[0], rebootstrap can
be done parallelly.
I have initialed some work at https://salsa.debian.org/zhangn1985/rebootstrap
corrently git commit msg is a mess, just recorder of my work.
reorder commit msg is on my TODO list, but I need
: MIT
Programming Lang: Python
Description : Graphical power status tool for Linux mobile devices
Powersupply is a simple GTK+3 application monitoring the status of power
supply nodes, exposing the current battery and USB power status through
a simple UI.
This application is aimed
Lang: C
Description : lightweight and configurable status panel (bar, for short)
for X11 and Wayland
yambar is a lightweight and configurable status panel (bar, for short) for X11
and Wayland, that goes to great lengths to be both CPU and battery efficient -
polling is only done when
/plasma-gamemode
* License : GPL, LGPL, BSD, CC0
Programming Lang: C++, QML
Description : Plasma extention for the GameMode daemon
Plasma status icon for Feral Interactive’s GameMode daemon (already
packaged as gamemode).
The package will be maintained under the Debian KDE Extras
Peter wrote:
>
>I've just noticed that the weekly live builds (both the free ones [0]
>and the unofficial non-free ones [1]) have not been updated since August
>9, 2021. Is this on purpose or did some machinery get stuck?
I disabled the testing live image builds after the bullseye release,
and I
Dear all,
I've just noticed that the weekly live builds (both the free ones [0]
and the unofficial non-free ones [1]) have not been updated since August
9, 2021. Is this on purpose or did some machinery get stuck?
Best regards,
Peter
[0] https://cdimage.debian.org/cdimage/weekly-live-builds
/soundcloud/go-runit
* License : Expat
Programming Lang: Go
Description : go library wrapping runit service status
go-runit go library wrapping runit service status
This library was vendored in prometheus-node-exporter and is now
packaged separately.
--
Benjamin Drung
Senior
ote that this is "family 6" Pentium-M processors, not "family 15" Pentium4-M.
I wouldn't mind the "i386" port baseline bumped up to i686-with-SSE2 (and MMX),
with gcc configured accordingly: I recall some reports that telling gcc to use
SSE2 really improved seve
Hello. 32-bit Pentium 4 user reading this out of personal interest
throwing in a comment.
If the choice is to primarily support pae or non pae for 32-bit moving
forward, then I suggest non-pae for the reason that everyone can use it.
If you have more than 4GB of memory you probably have a 64-bit
Am Sa, Dez 12, 2020 at 20:27:16 + schrieb Steve McIntyre:
It's still quite new, but we have a package in the archive for this now:
https://tracker.debian.org/pkg/debian-crossgrader
Well, yes, but it is only in unstable.
I tried to install it but apt wanted to replace many packages. Using
On Sat, Dec 12, 2020 at 08:27:16PM +, Steve McIntyre wrote:
> Stephan wrote:
> >Am Sa, Dez 12, 2020 at 18:09:02 +0200 schrieb Adrian Bunk:
> >>4. People who wrongly installed i386 on amd64-capable hardware.
> >
> >Well, some releases ago befor multi-arch I used to install i386 even on
> >am64-
On Wed, Dec 16, 2020 at 02:47:22PM -0500, Devops PK Carlisle LLC wrote:
I understand your point about 32 bit being updated forever, and perhaps
it does not need to be. Perhaps the happy medium would be to freeze it
at some point, but leave it available as-is so that legacy software with
32 bit d
I understand your point about 32 bit being updated forever, and perhaps
it does not need to be. Perhaps the happy medium would be to freeze it
at some point, but leave it available as-is so that legacy software with
32 bit dependencies can still be installed and run. In other words, no
longer deve
On Sun, Dec 13, 2020 at 11:40:29AM -0500, Devops PK Carlisle LLC wrote:
Being philosophically opposed to throwing a good machine into a
landfill, I tend to hang on to equipment for a long time. My
play/experimentation and last-ditch backup box is a 10 year old laptop.
I hear that, but at least
On 15.12.20 01:55, Russ Allbery wrote:
> Increasingly most of the people who work on Debian don't have i386
> hardware lying around, particularly i386 hardware that requires an i386
> kernel or that exercises the full range of older boot processes. If you
> do, testing and reporting good bugs woul
On Mon, Dec 14, 2020 at 05:13:54PM -0500, Calum McConnell wrote:
> Since (AFAIK) there is a substantial speed penalty to installing a non-pae
> kernel on a -pae processor,
The penalty is not using more than 4 Gb of RAM (the only related speed
penalty I know about is using PAE vs not using it).
--
On Mon, Dec 14, 2020 at 11:36 PM Adrian Bunk wrote:
> A bigger worry for i386 would be the availability of microcode updates
This is also a big problem for amd64, since only the newest
generations of Intel processors get BIOS/UEFI and or microcode
updates, so lots of amd64 users (including myself
Calum McConnell writes:
> A very fair point, and quite equitably put. If I was remotely
> comfortable tweaking kernels, or used a 32 bit machine regularly, I
> would be more comfortable volunteering. As it is, I have only really
> learned to maintain packages in the past few months, and I feel
On Mon, Dec 14, 2020 at 02:54:37PM -0800, Russ Allbery wrote:
>
> The quantity of hardware is useful data, but I think this is also a place
> where it's important to stress the specific problem that Debian has,
> namely that we need people to do the work.
>...
The list of Debian release architect
On Mon, 2020-12-14 at 14:54 -0800, Russ Allbery wrote:
> Calum McConnell writes:
> > The point I'm making is that i386 processors are still incredibly
> > common, and we shouldn't abandon their users.
>
> Not abandoning users is a powerful motivating force, but it still has to
> succeed in motiva
In practice, whether or not i386 will be dropped as release archticture
in bullseye will likely be decided by whether I will stay the only
committed porter, or whether other people will ASAP send (belatedly)
replies to the proter roll call [1].
This discussion started due to lack of people testi
Hi,
Quoting Russ Allbery (2020-12-14 23:54:37)
> > The point I'm making is that i386 processors are still incredibly common,
> > and we shouldn't abandon their users.
>
> Not abandoning users is a powerful motivating force, but it still has to
> succeed in motivating people. Debian can't make a
On Mon, Dec 14, 2020 at 01:22:11PM +0100, Ben Hutchings wrote:
> On Sun, 2020-12-13 at 01:53 -0800, Steve Langasek wrote:
> [...]
> > While the ongoing
> > costs of maintaining a full port were a consideration, of equal concern was
> > the fact that we believed we would not be able to provide secur
Calum McConnell writes:
> As I showed in my (slightly over dramatic, very over-long) email this
> morning, there are more people with i386 kernels than there are total
> users of every other release architecture. Even if you only look at
> non-pae kernels, its still about double the total instal
On Mon, 2020-12-14 at 10:02 -0800, Russ Allbery wrote:
> One possible intermediate option shy of dropping the i386 architecture
> would be to drop the i386 kernel and instead help all i386 installs
> switch
> to the amd64 kernel while still running i386 binaries. (That said, this
> will obviously
Ben Hutchings writes:
> I agree that kernel security support for i386 is seriously lacking.
> The Spectre mitigations were actually available for both x86
> architectures at the same time, but the initial Meltdown mitigation was
> amd64-specific and was not extended to i386 until Linux 4.19. Th
On Sun, 2020-12-13 at 01:53 -0800, Steve Langasek wrote:
[...]
> While the ongoing
> costs of maintaining a full port were a consideration, of equal concern was
> the fact that we believed we would not be able to provide security support
> for the architecture as a whole at par with other architect
Being philosophically opposed to throwing a good machine into a
landfill, I tend to hang on to equipment for a long time. My
play/experimentation and last-ditch backup box is a 10 year old laptop.
During COVID I spent a little time updating and upgrading it and came up
with this: https://go.carlis
On Sat, Dec 12, 2020 at 06:09:02PM +0200, Adrian Bunk wrote:
> > Ubuntu have chosen to support the first use-case, and only the first
> > use-case. They longer ship a complete, bootable i386 operating system;
> > instead, they have an i386 second-class-citizen architecture that
> > is sufficient to
Hi all,
As someone who runs amd64/i386 multiarch, this statement from Adrian:
> i386 hardware is so numerous and widely spread, that every tiny fraction
> of i386 users might be more users than half of our release architectures
> combined. It is not even clear whether this is just an exaggeration
Then there was the short netbook boom, but AFAIR some early ones
had 64bit CPUs but 32bit-only firmware.
My memory is that at the height of the boom the dominant processors
were the N270 and N280, which are 32-bit only. By the time 64-bit
netbook processors showed up the boom was on the dec
On Sat, 12 Dec 2020 at 18:09:02 +0200, Adrian Bunk wrote:
> 3. Computers that do support MMX and SSE2, but do not support 64bit.
Right, that's basically the second use-case I mentioned, but moving the
boundary for what we do and don't support to be more modern. We could
put the boundary anywhere w
Stephan wrote:
>Am Sa, Dez 12, 2020 at 18:09:02 +0200 schrieb Adrian Bunk:
>>4. People who wrongly installed i386 on amd64-capable hardware.
>
>Well, some releases ago befor multi-arch I used to install i386 even on
>am64-capable hardware if ram was quite low (=< 8GB) and if the chance
>wasnât
Am Sa, Dez 12, 2020 at 18:09:02 +0200 schrieb Adrian Bunk:
4. People who wrongly installed i386 on amd64-capable hardware.
Well, some releases ago befor multi-arch I used to install i386 even on
am64-capable hardware if ram was quite low (=< 8GB) and if the chance
wasn’t that low that you nee
On Tue, Dec 08, 2020 at 05:46:26PM +, Simon McVittie wrote:
>...
> I think it's necessary to consider what the purpose of the i386 port is,
> and set expectations and an appropriate baseline based on that.
>
> I see two possible use-cases for i386:
>
> 1. It's a compatibility layer for legacy
On Thu, Aug 20, 2020 at 10:24:18AM +0200, Bernd Zeimetz wrote:
> On 8/19/20 7:28 PM, Ansgar wrote:
> > Well, I can't fix it without creating dgit-ng (and setting up
> > infrastructure for that) as dgit upstream won't accept patches from me.
> That is just one of the reasons why I think that salsa s
On 8/19/20 7:28 PM, Ansgar wrote:
> Well, I can't fix it without creating dgit-ng (and setting up
> infrastructure for that) as dgit upstream won't accept patches from me.
That is just one of the reasons why I think that salsa should be used
for "official" services like tag2upload.
--
Ber
On Wed, 2020-08-19 at 10:15 -0700, Sean Whitton wrote:
> On Fri 14 Aug 2020 at 09:04AM +02, Ansgar wrote:
> > There are also other issues such as the system seeming to accepting
> > uploads from known-compromised keys last I looked at it, though
> > maybe security experts disagree how much of an is
Hello Ansgar,
On Fri 14 Aug 2020 at 09:04AM +02, Ansgar wrote:
> There are also other issues such as the system seeming to accepting
> uploads from known-compromised keys last I looked at it, though maybe
> security experts disagree how much of an issue this is in practice.
If what you say about
Hello Holger,
On Thu 13 Aug 2020 at 10:27PM GMT, Holger Levsen wrote:
> hi Sean,
>
> On Thu, Aug 13, 2020 at 02:22:15PM -0700, Sean Whitton wrote:
>> (It's worth noting that unlike salsa tags, the tags on dgit.debian.org
>> are immutable. The maintainer pushes a tag to salsa but tag2upload
>> co
Sean Whitton writes:
> Ian and I implemented something along these lines last summer and it's
> available to try from the archive; here is how:
> <https://spwhitton.name/blog/entry/tag2upload/>
>
> As to the current status: FTP Team members objected to having
>
hi Sean,
On Thu, Aug 13, 2020 at 02:22:15PM -0700, Sean Whitton wrote:
> (It's worth noting that unlike salsa tags, the tags on dgit.debian.org
> are immutable. The maintainer pushes a tag to salsa but tag2upload
> copies it to dgit.debian.org, where it becomes a permanent record.)
how is that a
Hello Thomas,
On Thu 13 Aug 2020 at 10:36PM +02, Thomas Goirand wrote:
> On 8/13/20 10:07 PM, Sean Whitton wrote:
>>
>> As to the current status: FTP Team members objected to having
>> uploader-signed git tags on dgit.debian.org be the canonical record of
>> an uploade
ething, there was a discussion a
>>> while ago about automatically generating a source package and uploading
>>> it whenever a Debian release is (signed-)tagged in Salsa.
>>>
>>> If I did remember correctly: may I kindly inquire what the status on
>>> tha
ly generating a source package and uploading
>> it whenever a Debian release is (signed-)tagged in Salsa.
>>
>> If I did remember correctly: may I kindly inquire what the status on
>> that is?
>
> I think I was the one with that idea [0], and I threw around some code la
>
> If I did remember correctly: may I kindly inquire what the status on
> that is?
I think I was the one with that idea [0], and I threw around some code last
winter, but I never really finished this; as I've stuck to using `dgit push-
source` for now.
The idea would be to have: a
Unless I'm grievously misremembering something, there was a discussion a
while ago about automatically generating a source package and uploading
it whenever a Debian release is (signed-)tagged in Salsa.
If I did remember correctly: may I kindly inquire what the status on
that is?
status bar content generator
luastatus is a universal status bar content generator. It allows the
user to configure the way the data from event sources is processed and
shown, with Lua. Its main feature is that the content can be updated
immediately as some event occurs.
It also avoids heavy
On 2020-06-18 11:18, Sebastiaan Couwenberg wrote:
> On 6/18/20 10:15 AM, mer...@debian.org wrote:
>> In addition to that, "Watch" column displays dashes ("-") only.
> That's due to #932296
Thanks a lot for the explanation!
Best,
Andrius
On 6/18/20 10:15 AM, mer...@debian.org wrote:
> In addition to that, "Watch" column displays dashes ("-") only.
That's due to #932296
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
1 - 100 of 2124 matches
Mail list logo
