On 2024-08-20 Helmut Grohne wrote:
> Hi fellow developers,
> (modified resend, as first attempt didn't arrive)
> please allow me to open a can of worms. Package removal from unstable.
> Deciding when it is time to remove a package from unstable is difficult.
> There may be users still and it is
On 2024-07-03 Alexandre Rossi wrote:
[...]
> #1073005 asks for the vendoring back of an unvendored library, arguing
> that this particular library is unmaintained upstream, implying that the
> vendored fork is better maintained.
> My view on this is that if the vendored fork is better maintained,
On 2024-06-14 Gürkan Myczko wrote:
[...]
> Have never done mass bug filings, any easy way, preferably something copy
> pastable,
> non-interactive.
Hej,
How about mass-bug(1) in devscripts?
cu Andreas
On 2024-05-29 Marco d'Itri wrote:
> On May 28, Andreas Metzler wrote:
>> I think it is bad choice to deliberately have different behavior for
>> freshly installed and upgraded systems. Offering upgrades has always
>> been one of the major selling points of Debian, an
On 2024-05-28 Luca Boccassi
wrote:
[...]
> - existing installations pre-trixie will get an orphaned tmpfiles.d in
> /etc/ that keeps the existing behaviour unchanged (no cleanup of
> /var/tmp)
[...]
Hello,
I think it is bad choice to deliberately have different behavior for
freshly installed an
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
On 2024-03-31 Andreas Metzler wrote:
[...]
> Afaict these are broken, though:
[...]
> tnat64 0.06-1
false positive, grep error.
On 2024-03-31 Andreas Metzler wrote:
> On 2024-03-31 Sven Joachim wrote:
[...]
>> Unfortunately the other four are not similar, but rather lacked a build
>> dependency on dpkg-dev (>= 1.22.5) which would have prevented their
>> migration to testing. Testing users on arme
On 2024-03-31 Sven Joachim wrote:
> On 2024-03-31 06:54 +0200, Andreas Metzler wrote:
> > On 2024-03-30 Julian Gilbey wrote:
[...]
> >> Looking through testing, I see the following t64 libraries present:
> >> libaio1t64
> >> libfyba0t64
> >
On 2024-03-30 Julian Gilbey wrote:
> My very limited understanding of this major transition was that the
> t64 libraries are being held in unstable until (almost) everything is
> ready, at which point there will be a coordinated migration into
> testing. But I've now been asked to upgrade somethi
On 2024-03-31 Wookey wrote:
[...]
> e.g. I remember it took me years to realise that I used _my_ public
> key for signing,
[...]
Good morning,
s/public/private/ - $recipient can then use your public key to verify
the sig.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other
On 2024-03-24 Samuel Henrique wrote:
> Hello everyone,
> Given our current time_t transition happening, which means packages
> are blocked from migrating to testing for weeks, and that unstable
> updates have become harder to apply, two critical CVE fixes for
> Firefox became impossible to get it
On 2024-03-02 Sven Joachim wrote:
> On 2024-03-02 08:47 +0100, Sven Joachim wrote:
>> On 2024-03-02 08:01 +0100, Andreas Metzler wrote:
>>> iirc it was recently proposed to add a suggestion to run dpkg --verify
>>> to the trixie upgrade notes to find missing
Hello,
iirc it was recently proposed to add a suggestion to run dpkg --verify
to the trixie upgrade notes to find missing files due to the usr-merge
transition. (Cannot find the reference right now).
However I just had file loss (due to libuuid changing its name to t64
and back again) and dpkg --
On 2024-02-26 John Goerzen wrote:
> Hi folks,
> As a person that frequently uploads to bookworm-backports, I am
> wondering how we are handling the time_t transition there?
> The picture of synchronization with testing is a little complicated over
> there. If you change the default build flags,
On 2024-02-09 John Goerzen wrote:
[...]
> So at the moment, I am unclear why there are bugs filed with severity
> serious that apparently cannot be fixed. Shouldn't they be normal with
> a tag wontfix until the relevant dpkg changes are in unstable?
> To put it another way, I'm not seeing why we
On 2024-02-06 Helmut Grohne wrote:
> Package: libselinux1t64
[...]> This looks fairly innocuous. We create a minimal sid chroot and install
> libselinux1t64 using apt. What could possibly go wrong? Well, apt thinks
> that it would be a good idea to avoid coinstalling breaking packages and
> first
On 2024-02-06 Alberto Garcia wrote:
> On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> > In fact, none of the t64 binaries currently being uploaded
> > to experimental have the final ABI either, we're just using
> > experimental to clear binary NEW.
> I was having a look at two o
On 2024-02-05 Tobias Heider wrote:
[...]
> As an active nvi user I would love to step up and help, but the biggest
> problem I see is that the choice of upstream project. Since the original
> is gone there isn't a clear successor.
> The BSDs all have their own forks which diverged over time (and
On 2024-02-03 Sebastian Andrzej Siewior wrote:
> On 2024-02-02 08:43:52 [-0800], Steve Langasek wrote:
>> debian-devel-announce wouldn't let me attach the file, but for those on
>> debian-devel at least, you can find the dd-list of to-be-NMUed source
>> packages attached.
> OpenSSL is on the lis
On 2024-01-21 Matthias Urlichs wrote:
> On 21.01.24 15:34, Andreas Metzler wrote:
> > However according to our release notes we only support upgrading from
> > release x to x+1, skipping releases is not allowed.
> I'm not talking about skipping releases but about partial
On 2024-01-21 Matthias Urlichs wrote:
> question: policy 3.5 states, rather unequivocally,
>Every package must specify the dependency information about other
>packages that are required for the first to work correctly.
> Now … does that apply to crossing release boundaries? Specifically,
On 2023-12-16 Jérémy Lal wrote:
[...]
> * Package name: acme.sh
> Version : 3.0.7
> Upstream Contact: w...@neilpang.com
> * URL : https://acme.sh
> * License : GPL-3
> Programming Lang: Shell
> Description : Pure unix shell script implementing ACME clien
On 2023-12-06 Dimitri John Ledkov wrote:
[...]
> May I also do a mass bug file against the above set of packages, at
> wishlist priority to nudge maintainers (or QA or Janitor) to make an
> upload?
> ideally bundled with any other reasonable modernisations. As such an
> algorithm indicates that th
On 2023-11-11 Michael Stone wrote:
> On Sat, Nov 11, 2023 at 11:50:31AM +0100, Andreas Metzler wrote:
> > you seem to have missed/deleted the paragraph where Ansgar suggested how
> > to do this *without* tradeoff. ("explicitly disable/enable build options
> > per arch&q
On 2023-11-10 Michael Stone wrote:
> On Fri, Nov 10, 2023 at 03:10:42PM +0100, Ansgar wrote:
>> Please avoid producing different results depending on the build
>> environment. That just results in non-reproducible issues in unclean
>> environments (suddenly different dependencies, different featur
On 2023-10-26 Vincent Lefevre wrote:
> On 2023-10-26 02:03:49 +0200, Vincent Lefevre wrote:
[...]
> Hmm... This seems to be due to a bug in the BTS when the bug was
> reopened for stable. At
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051563#25
> "Bug reopened Request was from Antonio
On 2023-10-15 Wookey wrote:
[...]
> OK. So I read all that, and learned a whole load of stuff I was quite
> happy not knowing about.
> However despite reading it all, and especially this bit:
> "Whenever I've maintained man pages in roff I tend to be precise in
> > the usage of - and \-, but TBH
On 2023-08-19 Diederik de Haas wrote:
> [please CC me as I'm not subscribed to debian-devel]
> On Mon, 17 Jul 2023 at 21:45:13 +1000, Hugh McMaster wrote:
> > On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote:
> > > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote:
> > > > Currently, t
On 2023-08-15 Boyuan Yang wrote:
[...]
> where .po file that contains translation is updated every time, causing dpkg-
> source to complain the diff and quit when building twoce in a row.
> Take https://tracker.debian.org/pkg/ibus-array as an example. The upstream
> project does not include .pot
Good morning,
guile-gnutls was uploaded almost a week ago to sid, but the unstable
autobuilders seem to ignore it.
https://buildd.debian.org/status/package.php?p=guile-gnutls
Is there anything I can do? The experimental uploads were picked up
seamlessly.
cu Andreas
--
`What a good friend you ar
On 2023-08-01 Helmut Grohne wrote:
[...]
> In moving crontab_setgid from lib to libexec, you effectively evade the
> moratorium and are entitled to also move from / to /usr. This is an
> action you can do right now. The move from /lib to /usr/libexec prevents
> the file loss scenario that spurred
On 2023-07-15 Markus Falb wrote:
> Hi, it’s Markus,
> …snip
> Index of /debian/dists/bookworm-updates/main
[...]
> The size of the gz files is 20, i.e. the unzipped files are empty.
> Is this by purpose?
Afaict (from looking at the Packages files) there are no Packagages yet
in bookworm-updates
On 2023-06-28 Helmut Grohne wrote:
> The category of generic changes includes
> imposing an ordering on initial unpacks (e.g. base-files first).
Hello,
I have not dug deeply into this but in the back of my mind a voice is
vaguely remebering that we already had multiple times wished we had this
i
On 2023-06-19 Sven Joachim wrote:
[...]
> If my above statements about debootstrap are correct, this will result
> in no dhcp-client being installed at all by debootstrap unless the
> override bug also requests bumping dhcpcd-base's priority from optional
> to important.
Not complety true. deboot
On 2023-06-07 Paul Wise wrote:
[...]
> There was another option mentioned earlier in the thread that could
> help resolve some aspects of these conflicts; make 32-bit arches
> (or just i386) support both time_t ABIs, like glibc and Linux do.
> The 64-bit time_t ABI would be the default but the 32
On 2023-05-20 Wookey wrote:
> On 2023-05-17 20:14 -0500, Richard Laager wrote:
>> They mention, "We likely have to complete Modern C porting first to remove
>> any instances of -Wimplicit-function-declaration otherwise the redirects in
>> glibc for e.g. time->time64 won't actually work."
>> Has t
On 2023-05-12 Ansgar wrote:
[...]
> The core issue as I see it is as follows:
[...]
> Do you think this summary of the issue is right?
I think Simon's reading of the situation as posted in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035904#30
makes a lot of sense.
cu Andreas
--
`What a g
On 2023-05-05 Simon Richter wrote:
[...]
> My proposal would be to put the onus on the client registering the
> diversion:
[...]
> - packages are encouraged to register both diversions
Hello,
That seems to be a rather ugly user interface, ("There is dpkg-divert on
Debian, but because the usrmer
On 2023-01-18 Jérémy Lal wrote:
> I just keep on removing apache2 on my system, and find it bad that some
> updates will reinstall it.
> It seems to be coming from dependencies on "apache2 | httpd-cgi" which
> favors the former (I have some httpd-cgi installed, just not apache2).
> Is it okay to o
On 2023-01-18 Otto Kekäläinen wrote:
> Lintian just started erroring on 'depends-on-obsolete-package
> lsb-base' on many of my packages yesterday. There are no new uploads
[...]
> Does somebody know what is going on?
> Example:
> E: mariadb-server: depends-on-obsolete-package Depends: lsb-base (>
On 2023-01-10 Sam Hartman wrote:
> > "Graham" == Graham Inggs writes:
> Graham> Hi All
> Graham> On Fri, 6 Jan 2023 at 00:33, Bastian Blank
> wrote:
> Graham> Would it be a bad thing to require all uploads that need to
> Graham> go through NEW (source and binary) to target e
On 2023-01-04 Markus Blatt wrote:
> Dear Anton,
> Am Wed, Jan 04, 2023 at 06:24:38AM +0100 schrieb Anton Gladky:
> > I am pleased to announce that the latest version of Boost, version
> > 1.81, is now available in Debian Testing [1].
> Thanks a lot.
>> We encourage all contributors whose packag
On 2022-12-16 Santiago Vila wrote:
> Greetings.
> I'm doing archive-wide rebuilds again.
> I've just filed 21 bugs with subject "Missing build-depends on tzdata"
> in bookworm (as tzdata is not build-essential).
> This is of course not fun for the maintainers, but it's also not fun
> for people
Gioele Barabucci wrote:
> On 05/12/22 18:19, Andreas Metzler wrote:
>> how do you avoid that people who still have got the transitional docker
>> (--> wmdocker) package installed end up being upgraded to real docker
>> (from docker.io)?
> How was the transition from
On 2022-12-09 Andreas Tille wrote:
[...]
> Thanks to Alexander Sulfrian who pointed out the Git repository
> featuring old tags that were obviously taken over from SVN I was proven
> wrong with the statement that there is no configure.ac any more.
> Unfortunately this is no simple drop-in with mo
On 2022-12-04 Hideki Yamane wrote:
> Hi,
> I'd like to propose wmdocker package would rename its source package
> from docker to wmdocker, and then docker.io package provides docker
> binary package and transitional docker.io package.
> Most of users who is not Debian expert still confusing
On 2022-11-14 Guerkan Myczko wrote:
> I would like to use Pre-Depends in the cadabra2 packge so it'll not break
> the jupyterhub notebook. It gets broken due to the package python3-notebook
> creating a symlink for the codemirror at
> /usr/lib/python3/dist-packages/notebook/static/components
> Now
you! Attached is a dd-list of those packages listed in the "Failures
> only" page in case somebody wants to have a quick glance whether their package
> is affected.
> Thanks!
> cheers, josch
[...]
> Andreas Metzler
>enblend-enfuse (U)
Works for me. - It is
On 2022-09-15 Scott Talbert wrote:
> On Thu, 15 Sep 2022, Andreas Metzler wrote:
[...]
> > A successful build is no guarantee for a working packaging though. e.g.
> > hugin errs out immediately when built with the newer wxWidgets.
> That is certainly true - and probably anot
On 2022-09-13 Scott Talbert wrote:
> Hi,
> wxWidgets 3.2 (a new API/ABI stable release) has been released a few months
> ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped
> supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx
> package users to wxw
On 2022-09-14 Paul Wise wrote:
> On Wed, 2022-09-14 at 07:41 +0200, Andreas Metzler wrote:
>> Is there a way to find all packages built against broken dh-fortran-
>> mod so all affected packages can be rebuilt?
> I am not sure of the correct regex, but the binary package contr
Package: libopenmpi-dev
Version: 4.1.4-2
Severity: serious
Hello,
it seems to be impossible to uninstall libopenmpi-dev:
(sid)root@argenau:/# dpkg --purge libopenmpi-dev
(Reading database ... 25167 files and directories currently installed.)
Removing libopenmpi-dev:amd64 (4.1.4-2) ...
rmdir: fail
On 2022-03-12 Hideki Yamane wrote:
> Is there any suggestion or guideline for pacakges that contain
> both systemd-timer unit setting and cronjob? Don't they conflict
> or not
Hello,
You want to skip running the cronjob on systems with systemd as init
systems. e.g. exim's daily cronjob works
On 2022-02-27 Adam Borowski wrote:
> On Sun, Feb 27, 2022 at 01:40:48AM +0100, Ben Hutchings wrote:
[...]
>> This should use "command -v", not which, I think?
> No, and the recent debacle revealed enough reasons that I'm pondering a MBF
> to change that _back_ in packages which followed the bad a
On 2022-02-24 Osamu Aoki wrote:
> I favor moving away from pre-dh7 packages and I support people pushing for
> it. But I
> am in intriguing situation with this effort. Can someone help me.
> At: https://udd.debian.org/cgi-bin/autoremovals.cgi
> I see:
> Osamu Aoki
>debian-history: buggy
On 2022-01-23 Thomas Dickey wrote:
> From: Richard Laager
>> On 1/23/22 10:04, Thomas Dickey wrote:
[...]
>> I see no other way to correct this but to add an epoch.
> agreed. Is there some way to further improve the transition?
>> As we see in this case, switching from version numbers to date-
On 2021-10-12 YaNing Lu wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: debian-devel@lists.debian.org
> * Package name: android-file-transfer-linux
> Version : 4.2.0
> Upstream Author : Vladimir
> * URL : https://github.com/whoozle/android-file-transfer-l
On 2021-09-14 John Paul Adrian Glaubitz wrote:
> I'm currently working on packaging KIWI [1] for Debian where I need to
> exclude on of the binaries from being installed into /usr/bin.
> I tried using "dh_install -Xkiwicompat" [2] but that doesn't work no
> matter what variation I'm trying, the b
On 2021-08-25 Niels Thykier wrote:
[...]
> As I understand it, the "have usrmerge package patch the dpkg database"
> approach will only work if we ensure that each and every package stop
> using / in bookworm+1.
Hello,
you missed the second part of the "plan". Editing dpkg database syncs
the db
On 2021-08-26 Timo Röhling wrote:
[...]
> However, Guillem also seems to think that dpkg can manage file
> symlinks in a real directory better than an directory symlinks in /,
> which is why he proposed symlink farms in the first place.
Hello,
Afaiui, the symlink farm would just work from dpkg's
On 2021-08-22 Guillem Jover wrote:
[...]
> The huge majority of files under /lib* (which is the actual bulk of them)
> should require no symlink farms. Many of the ones under /bin and /sbin
> (we are talking about around 240 packages here) might be switchable w/o
> compat symlinks after careful co
On 2021-07-27 Simon Josefsson wrote:
> Hi! I'm now resuming work on the libidn shared library transition, and
> I'm ready for the upload to experimental. I wanted to ping back here to
[...]
Hello Simon,
thank you, looks good to me.
cu Andreas
On 2021-07-27 Wouter Verhelst wrote:
> On Tue, Jul 27, 2021 at 02:13:33PM +0200, Andreas Metzler wrote:
[...]
>> Afaiu you are suggesting to do somethink like this instead and
>> immediately post bulleye release.
>>
>> pr
On 2021-07-27 Wouter Verhelst wrote:
> On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
>> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
>>> I've suggested previously that we can easily make it RC for bookworm to
>>> have a file outside a limited set of directories (
On 2021-07-20 Guillem Jover wrote:
> On Mon, 2021-07-19 at 16:41:42 +0200, Johannes Schauer Marin Rodrigues wrote:
>> So what what is actually the roadmap after the bullseye release?
>> What is the way forward? Should I rather file bugs with patches
>> against individual packages to move their fil
On 2021-06-12 Jonathan Carter wrote:
> On 2021/06/11 12:33, Raphael Hertzog wrote:
> > Jonathan explained that it wasn't easy for him due to reading over NNTP
> > and I also think that it's a bad default to have lists where custom
> > filtering is desirable for many.
> Ah, I haven't used NNTP in
On 2021-05-26 Guillem Jover wrote:
> On Tue, 2021-05-25 at 19:43:21 +0200, Andreas Metzler wrote:
[...]
> I'd probably instead make this a versioned Provides, so that the
> transitional package can be removed right away from systems, it does
> not interfere with the transitio
On 2021-05-24 Simon Josefsson wrote:
> Hi! This is for post-bullseye, but I appreciate guidance if anyone has
> time. Shared library version transitions trigger uncertainty in me.
> I want to upload a new upstream libidn release into Debian, but upstream
> has done a shared library transition.
On 2021-05-09 Harald Dunkel wrote:
> https://packages.debian.org/search?keywords=rsnapshot doesn't tell, so
> I wonder what is the recommended way to find out why rsnapshot (or any
> other package) has been dropped from Testing?
> rsnapshot is still in Sid. I found #986709, of course, but this
>
On 2021-04-03 Otto Kekäläinen wrote:
> Hello!
> In MariaDB we have over the years moved files around. A file that was first
> in e.g. mariadb-server-10.3 might have been moved to
> mariadb-server-core-10.3 and some years later to mariadb-client-core-10.5.
> The result is a massive debian/control
On 2021-03-26 Christoph Biedl wrote:
> a few days ago, I ran uscan on a package where I knew there was a new
> upstream version - just to encounter an validation error since the
> keys in debian/upstream/signing-key.asc had expired.
[...]
> Another about 40 distinct keys will expire within the nex
On 2021-03-07 Hideki Yamane wrote:
> X-debbugs-CC: debian-devel@lists.debian.org
> I've tried to remove files that was accidentally containts empty " ",
> comma "," and wildcard "*" via rm_conffile from dpkg-maintscript-helper.
> However, it returns an error like below.
> > dh_installdeb: err
On 2020-11-20 Ansgar wrote:
> I would like to propose to plan to move to support merged-usr-only over
> the following releases. The motivation is bugs like [1] where upstream
> developers just use `/usr/bin/rm` (or other binaries, or user scripts
> using /usr/bin/bash, or ...) unconditionally; th
On 2020-10-09 calumlikesapple...@gmail.com wrote:
> On Thu, 2020-10-08 at 18:45 +0200, Andreas Metzler wrote:
>> I do not get the reason for this change. Surely we do not expect
>> people to manually type
>> open penguin.jpeg
[...]
> I disagree. If you are developing
On 2020-10-07 Charles Plessy wrote:
> Hello everybody, hello Debian freedesktop.org maintainers,
> /bin/open has been kindly freed a couple years ago (#732796) and I would
> like to propose to repurpose it as a standard command for opening files,
> like on Mac OS and NextStep before it.
[...]
He
On 2020-08-29 Raphael Hertzog wrote:
> +URL: https://dep-team.pages.debian.net/deps/dep14/
[...]
| When a package targets any release that is not one of the usual
| development releases (i.e. stable releases or a frozen development
| release), it should be prepared in a branch named with the
In gmane.linux.debian.devel.general Niels Thykier wrote:
[...]
> 3) We followed up with an [update to the proposal] were debhelper would
> optionally expose some of the relevant directories (some by default,
> others on request) with symlinks while still supporting the new
> layout. I
On 2020-03-09 Sam Hartman wrote:
> I'm concerned about a leading . at least for:
> * the debian/tmp replacement
> * the replacement for the package install directories under debian.
> I think that maintaining those directories such that ls shows them will
> be more friendly for new maintainers.
On 2020-03-22 Bagas Sanjaya wrote:
> Hello,
> According to [Bashism Wiki](https://mywiki.wooledge.org/Bashism):
>> The comma operator is widely supported by almost everything except dash
>> and yash -- even posh and Busybox. In ksh93 however, it conflicts with
>> the decimal radix in locales whe
On 2020-03-08 Wookey wrote:
[...]
> So you need to package boringSSL before uploading this
> package.
[...]
https://packages.qa.debian.org/android-platform-external-boringssl
cu Andreas
Hello,
afaict we are moving to a usrmerge setup, i.e. with /lib just a
symlink to /usr/lib. So shouldn't packages start installing stuff to
/usr/lib instead of /lib? I would like to do that for libgcrypt, since
I would be able to shorten debian/rules by stopping to split stuff
between /lib (.so) a
On 2019-09-12 Jeff wrote:
> The package I uploaded yesterday failed to build[1]. In the buildd, 2 of
> 1000+ tests failed. Of course, I built in a clean sbuild for sid before
> I uploaded it, and the same package built fine on the newer Ubuntu
> distros on launchpad. So I'm hoping it was just a gl
Alexis Murzeau wrote:
> Le 13/08/2019 à 01:17, Daniel Leidert a écrit :
>> Am Montag, den 12.08.2019, 19:53 +0200 schrieb Marc Haber:
[...]
>>> I haven't heard that a debian/ only repository layout is possible with
>>> git-buildpackage before today.
>> Works nicely. I keep a file debian/gbp.conf
Theodore Ts'o wrote:
[...]
> Thanks, that's really helpful. One of the really frustrating things
> I've found about trying to use dh is that there is a real lack of
> examples which are more complicated than:
> #!/usr/bin/make -f
> #
> # See? dh is easy-peasy!
> %:
> dh $@
> Sure, th
Enrico Weigelt, metux IT consult wrote:
> I'm often seeing packagers directly putting dfsg'ed trees into their git
> repos, w/o any indication how the tree was actually created from the
> original releases.
[...]
> My preferred way (except for rare cases where upstream history is
> extremely huge
Jonathan Dowland wrote:
> On Tue, Nov 06, 2018 at 08:06:38PM +0100, Andreas Metzler wrote:
>> Could we document this a little bit better in the wiki? This is
>> completely different than on alioth, where collab-maint was suggested
>> for basically everything that did n
Guillem Jover wrote:
> On Tue, 2018-11-06 at 15:00:03 +, Matthew Vernon wrote:
[...]
>> that at least a MR is something I should have expected as a package
>> maintainer, not just commits to master?
> Assuming that packages is under the Salsa Debian namespace, then I
> think that's what you (
Holger Wansing wrote:
> I am curious about how to change an already existing git tag afterwards
> (means: change the commit it points to).
> Locally, I can change an existing tag, and then create it newly.
> But I cannot push it to the remote repo (get
> "! [rejected]139 -> 139 (a
Holger Levsen wrote:
> hi,
> maybe i'm stupid but i'm also failing now with my 3rd "quick" attempt of
> migration to salsa using the script...
> holger@moszumanska:~/alioth-migration$ ./migrate-repo -v -d
> /srv/git.debian.org/git/collab-maint/anarchism.git /debian/anarchism
[...]
> (oh and th
Tobias Frost wrote:
> On Mon, Apr 16, 2018 at 08:28:08AM +0800, Rolf Leggewie wrote:
>> https://anonscm.debian.org/gitweb/?p=collab-maint/gjots2.git
> You know that collab-maint stands for "Collaborative Maintaince"?
> IMHO by placing it into collab-maint, everyone is allowed / suggested
> to wo
Ole Streicher wrote:
> Sean Whitton writes:
>> On Sat, Apr 07 2018, Ole Streicher wrote:
[...]
>>> Sure, but why do we give up a common rule? I think the cases where
>>> d/watch does not work are not so rare (at least I have quite a number
>>> of them), and keeping them unified is not the worst t
In gmane.linux.debian.devel.general Philipp Hahn wrote:
> Hello APT developers,
> today I encountered the strange situation, that Debian-Stretch
> officially has 1.1.3-3, but if I do a "apt-get source snappy" I get 1.1.4-1:
[...]
> So how can I tell "apt-get source" to pull the "right" version,
Dimitri John Ledkov wrote:
> On 12 February 2018 at 10:28, Colin Watson wrote:
[...]
>> My recent attempt to upload grub2 2.02-3 was rejected due to
>> https://bugs.debian.org/745409, which I admit I've been putting off
>> dealing with for a while; but the relevant tag
>> (license-problem-non-fre
Dr. Bas Wijnen wrote:
> On Fri, Dec 29, 2017 at 10:43:58PM +0100, Alexander Wirt wrote:
>> On Fri, 29 Dec 2017, Philipp Kern wrote:
>> > Put a mapping into a git repository that DDs can push to? Make sure that
>> > it is fast-forwarded always? Then let people deal with it?
>> I am currently workin
Andreas Tille wrote:
[...]
> To answer Mattias question why not using source uploads all the time:
> Once I have build the package to see whether all those lintian issues
> are fixed I want to fix I have a sensible package to upload and somehow
> this workflow to upload what is just there remains.
On 2017-09-17 Alexander Wirt wrote:
[...]
> - Distribution lists for use in the Maintainer: field. We suggest
> that, with maybe some extra code, this use-case could be well served
> by the tracker.debian.org service for almost all purposes. For
> larger teams, such as the Debian P
Adrian Bunk wrote:
> On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
[...]
>> So, it would make more sense to have a par2 (or create a modern version
>> of it, actually) ECC layer on top of the compression layer, at which
>> point we can use one of the already supporte
Niels Thykier wrote:
> Andreas Metzler:
[...]
>> No, the encoding was not correct. Compare how you (your MUA) just did it in
>> this message with the rejected one.
>> From: =?UTF-8?Q?TOMAS_MARTI=c5=a0IUS?=
>> From: =?utf-8?b?VG9tYXMgTWFydGnFoWl1cyA8dG9tYXNAcHV
On 2016-12-28 TOMAS MARTIŠIUS wrote:
> 2016.12.28 09:09, Andreas Metzler rašė:
>> On 2016-12-27 TOMAS MARTIŠIUS wrote:
>>> Why I can't report bug using reportbug command? After reporting I get back
>>> e-mail with this message:
[...]
>> The From header does
1 - 100 of 651 matches
Mail list logo
