Re: broadcast error messages, unofficial Debian 12
Hi Alan, debian-devel is for discussion of the development of debian. Your query appears to be user support, which takes place on debian-user. I've set Reply-To: debian-user. On Wed, Dec 13, 2023 at 02:52:11PM -0500, Alan Corey wrote: > I can have 2 or more Zutty terminal windows running to work on a > program. When I get a compiling error in one terminal it gets > broadcast to both windows. > > This particular error is not anything in my code, I don't recognize any of > it, but it shows up because I had a warning in my stuff: > > W [main.cc:1161] (Unimplemented) unhandled OSC: '8;; > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-but-set-variable > ' > W [main.cc:1161] (Unimplemented) unhandled OSC: '8;;' I'm not familiar with Zutty but this message appears to come from your terminal, Zutty, which also explains why it appears in all of your terminal windows. An example of suxh a Zutty diagnostic is here: https://github.com/tomscii/zutty/issues/43 though it is not your specific one. So, you probably want to seek support from Zutty, e.g. at their github issues. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: testing for rootfs vs. /usr reproducibility regressions
Hi Tim, On Fri, Aug 20, 2021 at 05:29:54PM -0400, Timothy M Butterworth wrote: > I have a new-be question, what is the point of merged-usr? I put "debian merged-usr" into my favourite search engine and the first result was: https://wiki.debian.org/UsrMerge Does this page and those linked from it answer your question sufficiently as to what the point of the effort is? The link near to the bottom: http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge is quite informative. If you read those and it still isn't clear, it might be best to ask about it on debian-user, as debian-devel would really be for Debian Developers (who are mostly up to speed on this already to varying degrees) to decide about *how* to do it, not the basics of *why* or if it even *should* be done. It has been the default for some time for new installs and the tech-ctte already decided that it will be the only supported configuration for the next release after bookworm. At this point rehashing the whys of it would be repeating conversations had over the last several years, so I feel like it's a user documentation issue at this point if that's necessary. Cheers, Andy
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)
Hi, On Sun, Jul 18, 2021 at 05:54:33PM -0400, Polyna-Maude Racicot-Summerside wrote: > On 2021-07-18 5:07 p.m., Andy Smith wrote: > > I recommend understanding the issue before putting forth an opinion. > > > Maybe I shall correct what I said as it may be misunderstood. It's unclear to me why you've taken my reply to your mail on debian-user, and instead sent it to me privately and also to debian-devel. As neither of us are Debian Developers and you don't seem to have done much research regarding merged-/usr, I don't feel it is on-topic for me to continue that conversation with you on debian-devel. I recommend doing some more reading of these threads and the relevant wiki pages and if things are still unclear then asking user-level questions only on debian-user. Thanks, Andy
Re: Bug#968921: ITP: dotnet-core-3.1 -- Microsoft .NET Core SDK 3.0.100
Hello, On Sun, Aug 23, 2020 at 06:06:10PM -0500, Alistair Young wrote: > As Microsoft themselves point out, packaging this for main is > useful because it lowers the barrier to use of .NET Core to one > equivalent to other in-distro languages without requiring the > use of third-party repositories, especially when the runtime is > needed as a dependency of another package. Any comments on the privacy issues mentioned here?: http://dgl.cx/2020/08/dotnet-sdk-gdpr Should this be a concern for inclusion into Debian main? Would there be a way for Debian users to opt out of the telemetry by default, before any information is sent? Cheers, Andy
Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
Hello, On Tue, Jun 27, 2017 at 09:37:01AM +0200, Florian Weimer wrote: > > On Mon, 2017-06-26 at 08:34 +, Holger Levsen wrote: > > Other procesors aren't bug-free, they just don't get as many bug fixes. > > And the fixes aren't documented publicly at all. Similar to the time I was affected by problems with all Intel s3610 and s3710 SSDs which they spent a few weeks denying existed and then said was fixed in a firmware update whose release notes do not mention the issue. When pressed as to the details of the fix they just apologised and said that there hadn't been time to include mention of the problem in the release notes. Not even one line. https://communities.intel.com/thread/77801?start=15&tstart=0 It was a big hit to my trust in Intel and I stopped buying s3610 SSDs after this, but I don't expect other manufacturers are any better. Cheers, Andy
Re: Bug#656142: ITP: duff -- Duplicate file finder
Hello, On Tue, Jan 17, 2012 at 09:12:58AM +, Lars Wirzenius wrote: > rdfind seems to be quickest one, but duff compares well with hardlink, > which (see http://liw.fi/dupfiles/) was the fastest one I knew of in > Debian so far. Does anyone know of a duplicate file finder that can keep its database of seen files in an on-disk database instead of RAM? When looking for duplicates in a tree of hundreds of millions of files this can otherwise require quite a lot of RAM. Perhaps it can be worked around using lots of swap, but I would have thought this could lead to other processes getting swapped out, when generally I would rather that the duplicate finder just got slower itself. Cheers, Andy signature.asc Description: Digital signature
Re: master's mail backlog and upgrade time
On Fri, Nov 18, 2005 at 12:48:30PM -0500, Stephen Frost wrote:
> * Ian Jackson ([EMAIL PROTECTED]) wrote:
> > Stephen Frost writes ("Re: master's mail backlog and upgrade time"):
> > > Then bounce it locally. Duh. No reason to force master to deal with
> > > the bounce messages you feel are 'right' to send.
> >
> > I don't bounce it. I reject it at SMTP time with a 4xx or 5xx code.
>
> Congradulations! You've found the problem!
You would prefer that Ian:
a) inflict bounce spam scatter on the forged from addresses in the
malware and spam he doesn't want to accept delivery for; or
b) silently discards such mails resulting in the possibility of
legitimate mail being lost; or
c) just accepts the spam/malware?
I'm guessing (b), with the reasoning that if he chooses to reject
mail that his system thinks is bad then it's his problem to deal
with any false positives.
However in this day and age of the unwanted ratio of email being
greater than the wanted ratio, any system which accepts a lot of
unwanted email and then fails to deal with the refusal to accept by
systems further down the line is in real trouble. I do pretty much
the same as what Ian does, as I have explained, and so do many
others. It's the best way to deal with such mail: don't accept
what you're not prepared to deal with.
Instead of either side in this debate saying "Not my problem, you
should do this..." how about reaching some compromise? It sounds
like in the short term, Ian needs to discard some mail instead of
rejecting, and in the long term master needs to be able to cope with
this sort of thing. The absolute worst thing to do is to start
generating bounces to these forged addresses however.
My 2p,
Andy
signature.asc
Description: Digital signature
Re: master's mail backlog and upgrade time
On Wed, Nov 16, 2005 at 02:51:10PM +, Tim Cutts wrote: > On 15 Nov 2005, at 2:34 pm, Steve Langasek wrote: > > No: there is nothing "proper" about rejecting mail from a host > > that you have configured to forward mail for you. > > I can see where you're coming from, but it's unavoidable, isn't it? > Most of us probably have "accounts" which forward email to us, and > over which we have no control; for example in my case I have two, one > at debian.org, and one at Cambridge University (cantab.net), as well > as any number of mailing lists. If those upstream sources are more > lax about spam than the downstream SMTP receiver (whether chiark or > something else) then this sort of thing is inevitable.o Personally I have sa-exim SMTP reject viruses and high scoring spam, but if the message has precedence "bulk" or "list" then I discard it silently instead, in order to try and cut down on the number of sitations where my users will infuriate hosts that forward mail to them. Many MLMs will automatically kick you off the lists if you reject viruses they sent to you (hi, Phillipp Kern). It's not possible to catch everything though (users can set up forwards without my knowledge; they also can't predict which addresses will get lots of spam/malware), neither would I expect to be told I have to accept delivery of this email. In an ideal world both sides would be able to come to some arrangement that doesn't involve blackholing. signature.asc Description: Digital signature
