Otto Kekäläinen writes:
> Could you point me to some Debian Bug # or otherwise share examples of
> cases when a build succeeded locally but failed on official Debian
> builders due to something that is specific for sbuild/schroot?
I believe both these uploads
https://tracker.debian.org/news/128
Bastien Roucariès writes:
> Sensible-editor could now use EDITOR="emacsclient -n -c" and accept
> that sh -c accept
>
> My goal is to create a sensible-editor.desktop that will lauch by
> default the sensible-editor of choice
>
> For this I plan:
> - to allow by alternative mechanism to have an s
Bastien Roucariès writes:
>> b) but if im in a terminal (even if running in gnome) then i want a
>> terminal-based editor (based on what i installed)
>
> depends for me I prefer to run under emacsclient so you could do
> something like
> SENSIBLE_EDITOR='if [ -t 0 ]; then sensible-editor-GNOME ;
PICCA Frederic-Emmanuel writes:
> What about dog fooding ?
>
> for now we can setup a schroot and sbuild very easily and start to build a
> local repository in minutes.
>
> But when it comes to install gitlab and the CI system it is another story. So
> we rely on the central salsa instance.
f
> My overall impression is that this is a bold attempt, but the document could
> do
> with some copy-editing to whittle it down, make it more focussed, and possibly
> narrow the scope. E.g. perhaps Gitlab CI is too much in one go? Could that be
> done further down the line in a follow-up DEP?
I
Lukas Märdian writes:
> On 04.09.24 17:26, Marco d'Itri wrote:
>> Do we even have general documentation about configuring networking?
>
> Yes, there is a "NetworkConfiguration" page on the wiki and the Debian ref:
>
> * https://wiki.debian.org/NetworkConfiguration
I dont thinj this page is usefu
Helmut Grohne writes:
> I incline to agreeing with the scenario you depict. This can reasonably
> happen. I also think that David made a good case for it being unlikely
> to manage oneself into the buggy situation that way. And then the
> consequence is that you lost some possibly important files
Luca Boccassi writes:
> Hence, I am not really looking for philosophical discussions or lists
> of personal preferences or hypotheticals, but for facts: what would
> break where, and how to fix it?
cleaning /tmp or /var/tmp: users may lose files if they dont realise a
directory tmp can be clea
Luca Boccassi writes:
> On Mon, 6 May 2024 at 15:42, Richard Lewis
> wrote:
>>
>> Luca Boccassi writes:
>>
>> > Hence, I am not really looking for philosophical discussions or lists
>> > of personal preferences or hypotheticals, but for facts: what
Luca Boccassi writes:
> Hence, I am not really looking for philosophical discussions or lists
> of personal preferences or hypotheticals, but for facts: what would
> break where, and how to fix it?
- tmux stores sockets in /tmp/tmux-$UID
- I think screen might use /tmp/screens
I suppose if you
Luca Boccassi writes:
> qwhat would
> break where, and how to fix it?
Another one for you to investigate: I believe apt source and 'apt-get
source' download and extract things into /tmp, as in the mmdebootstap
example mentioned by someone else, this will create "old" files that
could immediately
Holger Levsen writes:
> I'm a bit surprised how many people seem to really rely on data in /tmp
> to survive for weeks or even months. I wonder if they backup /tmp?
I use /tmp for things that fall somewhere between "needs a backup" and
"unimportant, can be deleted whenever". I think all of the i
Simon McVittie writes:
> On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
>> The list of affected packages according to apt-cache showpkg is not
>> that long either:
>>
>> logcheck
> However, for packages that want to read a traditional /var/log/syslog
> or similar, notably logch
Russ Allbery writes:
> Simon McVittie writes:
>
>> I know fail2ban and logcheck do read plain-text logs (although as
>> mentioned, fail2ban already has native Journal-reading support too), and
>> I would guess that fwlogwatch, snort and xwatch probably also read the
>> logs.
>
> logcheck also ha
I couldnt work out where to ask this: Are emails about packages being
removed from testing generated using stale data on what bugs are open?
(are im not complaining about the process just trying to understand it)
According to https://udd.debian.org/udd-status.cgi data on bugs is
updated a lot les
Marco d'Itri writes:
> On Oct 05, Simon Josefsson wrote:
>
>> I would like that 'apt install signify' install OpenBSD's signify (from
>> the Debian 'signify-openbsd' package) and not the 2003 mail-related
>> signify perl script from the Debian 'signify' source package.
> Agreed: the current sign
Mo Zhou writes:
> The tone can change: http://paste.debian.net/1335055/
> LLMs are being improved rapidly over time.
>
> I guess it's due to some potential safety issues so that LLM uses a dull
> corporate tone by default.
I think it's slightly misdiagnosed here. to me, it comes accross as
"tedi
Lukas Märdian writes:
> On 23.09.24 12:27, Ansgar 🙀 wrote:
>> On Mon, 2024-09-23 at 12:22 +0200, Lukas Märdian wrote:
>>> On 22.09.24 15:58, Ansgar 🙀 wrote:
On Fri, 2024-09-20 at 13:12 +0200, Lukas Märdian wrote:
>>> The benefit that Netplan would provide in such cases is that
>>> debian-in
Fay Stegerman writes:
> [Added diffosc...@lists.reproducible-builds.org to Cc]
>
> * Fay Stegerman [2024-11-06 17:43]:
>> * Johannes Schauer Marin Rodrigues [2024-11-06 02:28]:
>> [...]
>> > Have one package diffoscope and one package diffoscope-full and you could
>> > even
>> > have a package
"Philipp Kern" writes:
> On Sun Nov 24, 2024 at 4:45 AM CET, Otto Kekäläinen wrote:
>> To me the whole free and open source movement is about collaboration,
>> transparency and the ethos of "given enough eyeballs, all bugs are
>> shallow".
> The "given enough eyeballs" always happened after the
Otto Kekäläinen writes:
> Hi all,
>
> I published a complete rewrite of the earlier draft as:
>
> https://salsa.debian.org/dep-team/deps/-/merge_requests/12
> DEP-18: Encourage Continuous Integration and Merge Request
> based Collaboration for Debian packages
>
> If you are in favor o
Jonathan carter writes:
>> https://surveys.debian.net/
I found the wording a bit confusing -- i expect you will get a lot of
votes in the reverse order to what is extended.
I suggest "ranking" and "choices" are a too similar: and the text seems
to use them backwards to normal usage in one place
Niels Thykier writes:
> # The bug template used
>
> Severity: important
> User: ni...@thykier.net
> Usertags: rrr-no-as-default-issue
>
> Dear maintainer,
>
> During a test rebuild for building packages "Rules-Requires-Root: no" as
^
minor point, but a
Otto Kekäläinen writes:
> Please also help Guido iterate on git-buildpackage so that it works
> well, is easy to debug, has good docs etc. Based on discussions in
> this thread there are a lot of people with misconceptions and
> polishing the docs would be the best action item right now.
Happy
Otto Kekäläinen writes:
> Basically you can start by forking
> https://salsa.debian.org/agx/git-buildpackage on Salsa and then start
> hacking away on the things you want to improve.
>
> If you want to do Python coding, fixing this issue could be an easy
> one to start with:
> https://bugs.debian
Soren Stoutner writes:
> On Monday, December 2, 2024 9:32:27 AM MST Andreas Tille wrote:
>> Attracting newcomers
>>
>>
>> In my own talk[mt3], I regret not leaving enough time for questions--my
>> apologies for this. However, I want to revisit the sole question raised,
>> wh
Andreas Tille writes:
> I wonder if we should reconsider the default assumption of package
> ownership.
(This is a reas objective, but) i wasnt sure how the following text would
achieve the above)
> Instead, we could introduce a file, such as
> debian/dont_touch_my_package (or a similarly named
Otto Kekäläinen writes:
> Salsa CI is a great system for all aspiring Debian packagers to test
> their packages before requesting review from mentors
> However, as there are still packages not using Salsa CI, I wonder is
> it straightforward enough for everyone?
>
I think the best solution woul
Otto Kekäläinen writes:
> Hi!
>
>> > Salsa CI is a great system for all aspiring Debian packagers to test
>> > their packages before requesting review from mentors
>>
>> > However, as there are still packages not using Salsa CI, I wonder is
>> > it straightforward enough for everyone?
>> >
>>
>>
Enrico Zini writes:
> [5] Do we have a thing that clones the running system into a throwaway
> VM?
systemd-nspawn claims to support this --
https://0pointer.net/blog/running-an-container-off-the-host-usr.html
Guillem Jover writes:
> Hi!
>
> On Sat, 2025-02-01 at 22:33:16 +0100, Abou Al Montacir wrote:
>> On Sat, 2025-02-01 at 17:35 +0100, Abou Al Montacir wrote:
>> > But also, in this particular case, it's not the issue of the spec but of a
>> > particular tool trying to enforce the rule.
>> >
>> > I
Gard Spreemann writes:
> While I personally think e-mail-based workflows can be quite nice, the
> BTS' asynchronous nature did cause me a lot of extra pointless work
> when I was an outsider attempting to learn the ropes. Being not 100%
> confident with the system, I way too often found myself wa
Tiago Bortoletto Vaz writes:
> Btw, for triage I used to suggest https://fabre.debian.net to
> newcomers. I had some hope that it could be a start for something
> bigger, so I tried to have access to the code to improve a few things
> but never had an answer from the maintainer :\
This looks lik
Michael Tokarev writes:
> BTW, is there a way for a systemd unit to take/inherit (security) settings
> from
> another unit?
You might want to look at the examples here
https://github.com/cyberitsolutions/prisonpc-systemd-lockdown/tree/main/systemd/system/postfix%40.service.d
(from Trent W. Buck
"Jonathan Dowland" writes:
> On Wed Dec 18, 2024 at 10:58 AM GMT, Henrik Ahlgren wrote:
>> Adding a couple of lines to the systemd unit should not add any new
>> dependincies to the package, or affect users of other init systems in
>> any way.
>
> That's a very good point. In which case that's li
Bill Allombert writes:
> Le Thu, Dec 12, 2024 at 02:36:51PM +, Jonathan Dowland a écrit :
>> The "Perl Problem" is a wider issue we should explore in much more depth.
>> I'm personally a little surprised if it's true that younger people are
>> unprepared to take a stab at hacking Perl. But si
Josh Triplett writes:
> Suppose that packages ship sample configuration files *that exactly
> match their defaults* (which should in general mean that everything is
> commented out) in some standardized path under /usr/share/doc/$package/
> (e.g. examples/etc), that makes it easy to see what pat
Marc Haber writes:
> For adduser's next release, I would like to discuss the following
> things:
>
> (1)
> Should Debian allow UTF-8 user names in the first place or should we
> restrict names for regular users to some us-ascii near set as well? (I
> think yes, we should)
would allowing utf-8 e
phil995511 - writes:
you say using backports is for advanced users yet you want users to be
able to choose their init systems? that's backwards. most users do not
care about the init system they use. adding backports and installing a
new kernel is not actually that difficult to do, and is easier
Crypticverse writes:
> Package: wnpp
> Severity: wishlist
> Owner: Crypticverse
> X-Debbugs-Cc: debian-devel@lists.debian.org, crypticvers...@gmail.com
>
> * Package name: linux-os-updater
> Version : 1.0.0
> Upstream Contact: Crypticverse
> * URL : https://github.co
Julien Plissonneau Duquène writes:
> Le 2025-01-24 13:00, Andrea Pappacoda a écrit :
>> Same for me. In addition, on the topic of making things easier for
>> new
>> contributors, when I first started using Salsa I felt lost in the
>> myriad
>> of features and options enabled by default. Not only
Otto Kekäläinen writes:
>> >> i think the barrier is likely to be "i didnt know you could do that?"
>> >> rather than "how do i use that?"
>> >
>> > Salsa CI is and has always been opt-in.
>>
>> oops - i meant the oppposite, ie make people have to opt out of having
>> it run, rather than have to
Enrico Zini writes:
> today I decided to upgrade from bookworm to trixie/testing[1][2]. I ran
> the upgrade in a gnome-terminal, and of course all gnome terminals in
> the system crashed halfway through the upgrade[1][3].
not much consolation, but: i supose this is why the release-notes
recommen
Lee Garrett writes:
>> On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek"
>> wrote:
>>>Network interface name changed: please update config files before reboot.
> P.S.: This failure mode isn't even documented in the release notes.
This does seem to be correct given that the OP was upg
44 matches
Mail list logo
