Re: Installer: 32 vs. 64 bit
On Fri, Oct 26, 2018 at 10:41:32PM +0200, Adam Borowski wrote: Or an user error. In either case, I don't get what a 32-bit _x86_ virtual machine would be good for. Are you teaching some code archeology? Do you want to prepare 32-bit images for something deeply embedded? Neither sounds an activity fit for your students. I'm not sure we are necessarily the experts in what is a fit activity for this teacher's students. For anything else, you want an amd64 kernel, possibly running i386 or x32 code. IMHO there are a remarkably small number of situations where x32 would be a sensible suggestion. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: salsa.debian.org: merge requests and such
Jonathan Dowland writes: > On Tue, Nov 06, 2018 at 03:42:01PM +, Matthew Vernon wrote: >>Hm, I had not quite appreciated that was the expected behaviour. Ah >>well, I can move it :) > > Please re-consider whether this trade-off (other people pushing to > master) is a small price to pay for the advantages to you and/or the > project of your package sources in the Debian project (more eyes, bus > factor…) Putting it under a personal namespace doesn't make it much less visible, and folk can still open MRs... Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Re: Installer: 32 vs. 64 bit
On Fri, Nov 09, 2018 at 11:36:36AM +, Jonathan Dowland wrote: > On Fri, Oct 26, 2018 at 10:41:32PM +0200, Adam Borowski wrote: > > Or an user error. In either case, I don't get what a 32-bit _x86_ virtual > > machine would be good for. Are you teaching some code archeology? Do you > > want to prepare 32-bit images for something deeply embedded? Neither sounds > > an activity fit for your students. > > I'm not sure we are necessarily the experts in what is a fit activity > for this teacher's students. If his students were doing code archaeology or deep embedded, such areas require enough base skills that getting spooked by 32 vs 64 bits would be beyond them. Less variants -> less confusion -> less pain for the teacher. There are architectures where running a 32-bit VM might be a worthy use of your time, but it's not the case here. > > For anything else, you want an amd64 kernel, possibly running i386 or x32 > > code. > > IMHO there are a remarkably small number of situations where x32 would be a > sensible suggestion. As a lapsed x32 porter, I agree. But it's still more sensible than i386. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road? For thousands of years, the ⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the ⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk. To where it came ⠈⠳⣄ together with silk (judging by today's amber stalls).
Re: salsa.debian.org: merge requests and such
On Fri, Nov 09, 2018 at 11:54:50AM +, Matthew Vernon wrote: > Jonathan Dowland writes: > > On Tue, Nov 06, 2018 at 03:42:01PM +, Matthew Vernon wrote: > >>Hm, I had not quite appreciated that was the expected behaviour. Ah > >>well, I can move it :) > > > > Please re-consider whether this trade-off (other people pushing to > > master) is a small price to pay for the advantages to you and/or the > > project of your package sources in the Debian project (more eyes, bus > > factor…) > > Putting it under a personal namespace doesn't make it much less visible, > and folk can still open MRs... This seems like a little bit of an overreaction to somebody removing a single redundant line from a control file, though. Is moving it really worth the added friction? -- Colin Watson [cjwat...@debian.org]
Bug#913311: ITP: slinkwatch -- automatic enumeration and maintenance of Suricata monitoring interfaces
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: slinkwatch Version : 1.0 Upstream Author : DCSO GmbH * URL : https://github.com/DCSO/slinkwatch * License : GPL Programming Lang: Go Description : automatic enumeration and maintenance of Suricata monitoring interfaces slinkwatch is the Suricata Link Watcher, a tool to dynamically maintain interface entries in Suricata's configuration file, depending on what network interfaces are connected. It is meant to ease deployment of identical sensor installations at many heterogenous sites, allowing to make full use of the sensor resources in the light of varying monitoring volume.
Bug#913313: ITP: balboa -- server for indexing and querying passive DNS observations
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: balboa Version : 1.0 Upstream Author : DCSO GmbH * URL : https://github.com/DCSO/balboa * License : BSD-3-clause Programming Lang: Go, C Description : server for indexing and querying passive DNS observations balboa is the BAsic Little Book Of Answers. It consumes and indexes observations from passive DNS collection, providing a GraphQL interface to access the aggregated contents of the observations database. The software can handle passive DNS data aggregated from metadata, for example gathered by IDS tools like Suricata, and various other dedicated collectors.
Re: salsa.debian.org: merge requests and such
(Please do not CC me, I am subscribed to the list and have set MFT accordingly, or at least think I have.) On Fri, Nov 09, 2018 at 11:54:50AM +, Matthew Vernon wrote: Putting it under a personal namespace doesn't make it much less visible, and folk can still open MRs... Oh I beg to differ, there's a huge difference of visibility between the "main" Debian project, to which we are all members, and personal namespaces. Not least the lack of any implied rules of behaviour. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Installer: 32 vs. 64 bit
On Fri, Nov 09, 2018 at 01:40:59PM +0100, Adam Borowski wrote: If his students were doing code archaeology or deep embedded, such areas require enough base skills that getting spooked by 32 vs 64 bits would be beyond them. Everyone starts somewhere, even code archaeologists. At my former School a Lecturer taught Operating Systems by getting the students to write kernel modules for MINIX on a VM (networking iirc). I'm sure the majority of those students would get horribly tied up in 32 vs 64 issues like this if they experienced them; despite that, they broadly succeeded in writing the kernel modules and passing the course. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#913319: ITP: ethflux -- InfluxDB data gatherer for ethtool-style network interface information
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: ethflux Version : 1.0 Upstream Author : DCSO GmbH * URL : https://github.com/DCSO/ethflux * License : BSD-3-clause Programming Lang: Go Description : InfluxDB data gatherer for ethtool-style network interface information ethflux is an InfluxDB data gatherer for ethtool-style network interface information. It uses the Linux SIOCETHTOOL ioctl interface to obtain network interface statistics and other runtime data and outputs them in InfluxDB's line protocol format for further propagation.
Bug#913334: ITP: golang-github-justinas-alice -- Painless middleware chaining for Go
Package: wnpp Severity: wishlist Owner: Raúl Benencia * Package name: golang-github-justinas-alice Version : 0.0~git20171023.03f45bd-1 Upstream Author : Justinas Stankevičius * URL : https://github.com/justinas/alice * License : Expat Programming Lang: Go Description : Painless middleware chaining for Go Alice provides a convenient way to chain HTTP middleware functions and the app handler. . It transforms: go Middleware1(Middleware2(Middleware3(App))) to go alice.New(Middleware1, Middleware2, Middleware3).Then(App) . None of the other middleware chaining solutions behaves exactly like Alice. Alice is as minimal as it gets: in essence, it's just a for loop that does the wrapping for you. This is a dependency of Shoelaces (#905723) and will be maintained under the Go team umbrella.
Bug#913333: ITP: golang-github-namsral-flag -- Parse flags, environment variables and config files
Package: wnpp Severity: wishlist Owner: Raúl Benencia * Package name: golang-github-namsral-flag Version : 1.7.4-alpha+git20170814.67f268f-1 Upstream Author : Lars Wiegman * URL : https://github.com/namsral/flag * License : BSD-3-clause Programming Lang: Go Description : Parse flags, environment variables and config files Flag is a drop in replacement for Go's flag package with the addition to parse files and environment variables. This library is a drop-in replacement of Go's native flag package that supports the third factor twelve-factor app methodology: storing the config in the environment. This is a dependency of Shoelaces (#905723) and will be maintained under the Go team umbrella.
Re: salsa.debian.org: merge requests and such
Colin Watson writes: > On Fri, Nov 09, 2018 at 11:54:50AM +, Matthew Vernon wrote: >> Jonathan Dowland writes: >> > On Tue, Nov 06, 2018 at 03:42:01PM +, Matthew Vernon wrote: >> >>Hm, I had not quite appreciated that was the expected behaviour. Ah >> >>well, I can move it :) >> > >> > Please re-consider whether this trade-off (other people pushing to >> > master) is a small price to pay for the advantages to you and/or the >> > project of your package sources in the Debian project (more eyes, bus >> > factor…) >> >> Putting it under a personal namespace doesn't make it much less visible, >> and folk can still open MRs... > > This seems like a little bit of an overreaction to somebody removing a > single redundant line from a control file, though. Is moving it really > worth the added friction? It's more a reaction to the "if you didn't want random commits onto master, you shouldn't have put it under debian/" policy. I don't, so I shouldn't have. Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Re: salsa.debian.org: merge requests and such
Jonathan Dowland writes: > On Fri, Nov 09, 2018 at 11:54:50AM +, Matthew Vernon wrote: >>Putting it under a personal namespace doesn't make it much less visible, >>and folk can still open MRs... > > Oh I beg to differ, there's a huge difference of visibility between the > "main" Debian project, to which we are all members, and personal > namespaces. Not least the lack of any implied rules of behaviour. That's what Vcs-Git et al are for, isn't it? Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Re: salsa.debian.org: merge requests and such
Matthew Vernon writes ("Re: salsa.debian.org: merge requests and such"):
> Colin Watson writes:
> > This seems like a little bit of an overreaction to somebody removing a
> > single redundant line from a control file, though. Is moving it really
> > worth the added friction?
>
> It's more a reaction to the "if you didn't want random commits onto
> master, you shouldn't have put it under debian/" policy. I don't, so I
> shouldn't have.
We're not talking about "random" commits, though, are we ? We're
talking about a commit that a DD thought was very likely a good idea.
Were they wrong ? It would be nice to have a proper reference.
It might be nice to have clearer guidance about exactly what level of
certainty a DD ought to have before making such a commit.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: salsa.debian.org: merge requests and such
Ian Jackson writes:
> Matthew Vernon writes ("Re: salsa.debian.org: merge requests and such"):
>> Colin Watson writes:
>> > This seems like a little bit of an overreaction to somebody removing a
>> > single redundant line from a control file, though. Is moving it really
>> > worth the added friction?
>>
>> It's more a reaction to the "if you didn't want random commits onto
>> master, you shouldn't have put it under debian/" policy. I don't, so I
>> shouldn't have.
>
> We're not talking about "random" commits, though, are we ? We're
> talking about a commit that a DD thought was very likely a good idea.
> Were they wrong ? It would be nice to have a proper reference.
The particular commit was fine (and had it come as a MR or bug report or
whatever I'd have had no problem with it at all).
Regards,
Matthew
--
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org
I resigned in 2004
I quit Debian development back in 2004. This was a moral decision, based on the malfeasance of the project secretary over the "Editorial changes" GR. For some reason, Debian as a project failed to notice that I had quit, even though my wi...@debian.org email address was deliberately forwarded to a non-functional email address (in part because of the complete catastrophe that was the Debian spam filtering system at the time). Over the last couple of months, the MIA team has been trying to get me to participate in some inane bureaucracy. I have been ignoring their emails. Today, they took it to a new level by encouraging everybody who knows me to pester me to answer my emails from them. This is not acceptable. Leave me alone. Your project left me long ago. Do not contact me with regard to Debian bullshit.
Re: salsa.debian.org: merge requests and such
On Fri, Nov 09, 2018 at 05:41:53PM +, Matthew Vernon wrote: > The particular commit was fine (and had it come as a MR or bug report or > whatever I'd have had no problem with it at all). I'm not sure why you are so bothered by it. Granted, when I first experienced a git push not working after I uploaded some package, I was also puzzled and a bit annoyed that someone pushed into the master branch of 'my' package, but upon reflection I decided: - this is great. someone contributed to make *many* Debian packages better. - git wise, I think, I reverted these commits, pushed my changes and merged the reverted commits again. No big deal, except a bit of messy history. There are several strategies to deal with, I choose the quickest path. - I also learned to first do 'git fetch' before uploading. Maybe someone put another present into git? So, yes, at first I was surprised too, now I'm gladly looking forward to more of these contributions. That said, there is one exception, src:piuparts, where I'll dislike drive-by commits to master. Why is explained in the CONTRIBUTING document in the source code. Here I will most likely again just revert the commits in the master branch, merge them in the develop branch and tell the commiter. And surely, if you don't like other people contributing to 'your' stuff directly, you are absolutly free to not have your packages in the debian namespace. I do however think that having packages there by default is a very good idea. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: I resigned in 2004
Hi, On Fri, Nov 09, 2018 at 10:56:57AM -0800, Matthew Wilcox wrote: > For some reason, Debian as a project failed to notice that I had quit, Probably because even at that time there were procedures that weren't followed, and apparently nobody after then bothered to check your status *and* follow up appropiately to clean it up. > even though my wi...@debian.org email address was deliberately forwarded > to a non-functional email address (in part because of the complete > catastrophe that was the Debian spam filtering system at the time). I don't know what happened back then to your forwarding address (for however strange your statement looks to me), so I can't quite comment here. > Over the last couple of months, the MIA team has been trying to get me to > participate in some inane bureaucracy. I have been ignoring their emails. I can say that the MIA team didn't try to get you recently. That was Jonathan McDowell that apparently was in contact with you and -according to the note he left- started on 2018-08-25 the process¹ to have you properly retire. Missing the required follow up from your side² I sent a follow up on 2018-09-30 completely out of curtesy as from my side it just seemed like you missed the mail but you were interested in cleaning your position. > Today, they took it to a new level by encouraging everybody who knows > me to pester me to answer my emails from them. This is not acceptable. Today, more than two months after Jonathan started the process, I proceed to follow the "remove" route instead of the "retire" route, which triggers an email in debian-private@. > Leave me alone. Your project left me long ago. Do not contact me with > regard to Debian bullshit. ACK, we will have DAM remove you instead of retire. I suppose there is no harm as you don't seem interested in the "benefits" that the "retired" DDs have over the "removed" ones. I'm sorry to have bothered you more than necessary. Good bye, and thank you for your contributions you made back then! ¹ https://nm.debian.org/process/539 ² which would have consisted in following one link in that mail, and then click a single other button; really, nothing more -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: salsa.debian.org: merge requests and such
On Fri, Nov 09, 2018 at 05:41:53PM +, Matthew Vernon wrote:
> Ian Jackson writes:
> > Matthew Vernon writes ("Re: salsa.debian.org: merge requests and such"):
> >> Colin Watson writes:
> >> > This seems like a little bit of an overreaction to somebody removing a
> >> > single redundant line from a control file, though. Is moving it really
> >> > worth the added friction?
> >>
> >> It's more a reaction to the "if you didn't want random commits onto
> >> master, you shouldn't have put it under debian/" policy. I don't, so I
> >> shouldn't have.
> >
> > We're not talking about "random" commits, though, are we ? We're
> > talking about a commit that a DD thought was very likely a good idea.
> > Were they wrong ? It would be nice to have a proper reference.
>
> The particular commit was fine (and had it come as a MR or bug report or
> whatever I'd have had no problem with it at all).
I guessed that the particular commit was
https://salsa.debian.org/debian/pcre2/commit/6c14b51ddfc45604fd805bcadc810d437f09a30f.
(The same developer has also been doing a number of other minor cleanups
in many other packages along the same lines.)
Honestly, I think it's better for Debian as a whole that people should
be able to do that kind of bulk cleanup with absolutely minimal
friction, rather than the "open 2000 bugs, wait a year, find that 500 of
them are still open" dance that I'm sure many of us are familiar with;
it's one thing when it requires non-trivial thought or testing or when
the substance might in some way be controversial, but when the commits
are this simple it's hard to see a cost-benefit analysis working out
favourably for filing a large number of bugs or even MRs, either for the
developer doing the original work or the maintainers receiving the
patches.
(I do have a few of the packages I maintain in slightly more restrictive
namespaces, admittedly, in cases where my opinion is that working on
them requires an unusual amount of care, but they're still team
namespaces; and I could be convinced that I should open them up further.
I mostly use the "debian" namespace, though, and am happy not to have to
put more than the absolute bare minimum of effort into dealing with the
sort of "chore" commits being done directly here as a result.)
--
Colin Watson [cjwat...@debian.org]
Re: salsa.debian.org: merge requests and such
On Fri, Nov 09, 2018 at 07:42:13PM +, Holger Levsen wrote: > Granted, when I first experienced a git push not working after I > uploaded some package, I was also puzzled and a bit annoyed that someone > pushed into the master branch of 'my' package, but upon reflection I > decided: > > - this is great. someone contributed to make *many* Debian packages > better. > - git wise, I think, I reverted these commits, pushed my changes and > merged the reverted commits again. No big deal, except a bit of messy > history. There are several strategies to deal with, I choose the > quickest path. > - I also learned to first do 'git fetch' before uploading. Maybe someone > put another present into git? For the record, I think the strategy I took was even quicker: * "git push --follow-tags" *before* uploading (this has been my invariable habit for years) * oh, push failed. "git pull --rebase" and resolve conflicts * check new commits * build source package again, test, push, upload -- Colin Watson [cjwat...@debian.org]
Re: Installer: 32 vs. 64 bit
> Filing a bug on src:virtualbox with severity 'wishlist' or 'normal' for this > issue to discuss it with the maintainer of the virtualbox package(s) seems a > logical thing to do. Unfortunately, we're speaking about running Debian under VirtualBox under Windows, so it would need to be something that happens in VirtualBox upstream.
Re: Installer: 32 vs. 64 bit
> Or an user error. In either case, I don't get what a 32-bit _x86_ virtual > machine would be good for. Are you teaching some code archeology? Not at all. We're trying to make it compulsory for first year students to have a Unix installation on their personal machine. In practice, this means any of native Linux, native Mac OS, or virtualised Linux. (We've found Cygwin to be confusing, and we haven't looked at WSL.) Since we're trying to get this to scale across a few hundred eighteen-year olds (smart ones, thankfully), we're seeing all sorts of user errors. -- Juliusz
Re: Installer: 32 vs. 64 bit
On Fri, Nov 09, 2018 at 05:31:00AM +, Chris Knadle wrote: > A logical place to check or the lack of BIOS virtualization features and show > an > error message for this would be within the .postinst script for the virtualbox > package in Debian. This way when Virtualbox is installed the user installing > it > can be warned that VT-x or AMD-V isn't active and give a hint as to how to fix It's pretty easy to miss messages in postinst scripts; sometimes a few hundred go flying past and some of them print information that is noise at best. Something this important probably ought to be a message in the GUI somewhere, since people expect to interact with VirtualBox via GUI. The cpu-checker package in Ubuntu might be worth stealing. The kvm-ok script runs a handful of small checks to try to diagnose if KVM-based virtualization acceleration will work or not: $ kvm-ok INFO: /dev/kvm exists KVM acceleration can be used https://launchpad.net/ubuntu/+source/cpu-checker https://launchpad.net/cpu-checker Thanks signature.asc Description: PGP signature
Re: I resigned in 2004
On Fri, Nov 09, 2018 at 09:29:30PM +0100, Mattia Rizzolo wrote: I would like to start by highlighting one very important line from my last email to you: > > Do not contact me with regard to Debian bullshit. And yet, you did. Fuck you. Do not contact me again. I shall consider any further contact (from you or anyone else in regards to this matter) as harassment, and I shall seek legal counsel. Your email is full of self-justifications and I have not the slightest interest in refuting any of them. You are a computer programmer pretending to be an HR department. You are no good at it. You have to appreciate that I owe you nothing. You don't pay me. It is not incumbent on me to do anything for you. Get a professional to review your procedures, because your procedures are completely inadequate. Causing people who I consider my friends to harass me to do something I find incredibly difficult and painful to do is not OK. You've made them complicit in hurting me. You've dragged up some awful memories from *fourteen* years ago, when I was betrayed by people who I thought were my friends. I don't care that you didn't do it on purpose. You've hurt me. And you made my friends hurt me. Again.
