Re: xz backdoor
On Fri, Mar 29, 2024 at 09:09:45PM +0100, Sirius wrote: > Hi there, > > This is quite actively discussed on Fedora lists. > https://www.openwall.com/lists/oss-security/2024/ > https://www.openwall.com/lists/oss-security/2024/03/29/4 > > Worth taking a look if action need to be taken on Debian. > https://tracker.debian.org/news/1515519/accepted-xz-utils-561really545-1-source-into-unstable/ Groeten Geert Stappers -- Silence is hard to parse
main-dev
Hello, This is about evolving Debian further, for getting beyond a growing pain. In upstream sources are many libraries, crates, modules and such[0]. Those files are needed during development[1] and packaged for Debian for that reason. They are not needed for running the compiled program. What I want, is to explore if we put those libraries in a special corner of the Debian Package Archive, something like 'main-dev'. Having a different kind of packages means we can threat them differently. Which benefits will it bring? One such thing could be that multiple versions of same library exist. ( foo version 0.2 needing baz v0.3.4 and bar v2.0 needing baz v0.3.3 ) Actual goal I want to achieve (goal we Debian should want to achieve) is having various ways to improve the process of getting upstream development files into Debian. Yeah, currently I think it is too tedious to keep with the pace of upstream. What would be needed to catch-up? Regards Geert Stappers [0] to complete the list, additions welcome. [1] Also for building and reproducible rebuilding -- Silence is hard to parse
Re: Regarding: Package name discord ITP: discord a modern voice & text chat app
On Mon, Jul 03, 2023 at 11:35:33AM +0200, Typical wrote: > On Mon, Jul 03, 2023 at 11:33:25AM +0200, We can do better wrote: > > On Mon, Jul 03, 2023 at 10:38:39AM +0200, Andrey Rakhmatullin wrote: > > > On Mon, Jul 03, 2023 at 10:11:50AM +0200, Filippo Rusconi wrote: > > > > I've never heard that Discord was Free Software. > > > Of course it isn't. > > > > Not yet. > > Hello Andrey, With 'We can do better' is meant Stop attacking community members In case this message feels as an attack, then I might have made my point. Regards Geert Stappers Has hope that Signal Noise Ratio of wrar improves. signature.asc Description: PGP signature
Re: artwork for bookworm?
Summary: Retransmit On Sat, Oct 22, 2022 at 08:58:32PM +0200, Paul Gevers wrote: > Dear all, > > Today I started the Release Team Checklist [1] and noticed: > [ ] Theme (artwork) design should be finalised and decided > > I just found two small threads on debian-desktop [2, 3], but I'm not aware > of any further activity on the artwork front. Do we have volunteers to push > for the bookworm artwork creation and selection (like [3])? It's not going > to happen by itself. (I might have missed the activity, pointers to it would > be appreciated). > > Paul > who is *not* going to do that. > Time will tell if someone stepped forward or that we just re-used an existing design. Regards Geert Stappers [1] https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/BookwormCheckList [2] https://lists.debian.org/debian-desktop/2022/04/msg0.html [3] https://lists.debian.org/debian-desktop/2022/08/msg0.html [4] https://wiki.debian.org/DebianDesktop/Artwork/Bookworm -- Silence is hard to parse
Re: Bug email is not getting to me
On Sun, Sep 25, 2022 at 03:42:40PM -0500, Steven Robbins wrote: > Hi, > > When I first started with Debian many many years ago, I would routinely see > email for bug reports submitted against packages I maintain, and responses to > said bugs. Nowadays I get essentially none of that. The only way I see such > responses is by perusing bugs via the web interface -- which I do > infrequently > so messages languish. > > I may have missed when something changed over the years. Is there something > I > must do to get bugs.debian.org to reliably send me email? > > I just noticed today that this applies even to responses that apparently > directly CC my debian address; e.g. https://bugs.debian.org/cgi-bin/ > bugreport.cgi?bug=1020397;msg=10 > > I literally searched my mail logs for the Message-ID in question and it is > not > reported. So it appears to have been hung up somewhere. How can I debug > this? > > I have sent a test email to my debian address and it came through. So I > think > email is normally being delivered. Just not from bug reports. > Who is running the incoming mail server? > P.S. This has been happening for months if not years. It's just that I > haven't been motivated to ask the question until now. So the change might be "fresh". > P.P.S. I don't subscribe to any debian lists, so it is appreciated to > directly cc me in replies. You are welcome Groeten Geert Stappers Runs his own mail server -- Silence is hard to parse
Re: how about telegram channel
On Wed, Jul 20, 2022 at 04:40:01PM +0500, Andrey Rahmatullin wrote: > On Wed, Jul 20, 2022 at 11:09:57AM +0200, Pierre-Elliott Bécue wrote: > > I'd try to stay closer to FOSS decentralized solution like Mattermost or > > Rocket Chat (not sure how and if it evolved to the point of being > > usable). > Shouldn't this have gone to -curiosa instead? > Please lead by example. Groeten Geert Stappers DD -- Silence is hard to parse
Re: how about matrix channel, it is available
On Tue, Jul 19, 2022 at 11:03:00PM +0200, Kyle Robbertze wrote: > On 2022/07/19 22:12, Alastair McKinstry wrote: > > On 19/07/2022 21:04, Wookey wrote: > > > On 2022-07-19 21:01 +0200, Bartosz Fenski wrote: > > > > > > > > Anyone interested in switching to some more modern channels of > > > > communication? > > > > > > > Matrix please. It's free software all the way through. We can run our > > > own server. Not-mobile-phones are 1st class clients. > > > > > > I'm increasingly using it to replace IRC (with bridges if > > > appropriate). I'd be happy to see debian move channels from IRC to > > > Matrix. I'm not happy about moving them to Telegram or Signal, which > > > are obviously a great improvement on Whatsapp but still only > > > somewhat-free. Telegram has non-free back-end. Signal is presumably OK > > > if you run your own back-end, but you try to use the centralised one > > > then you can't build your own client (or at least it's made extremely > > > difficult). Signal requires an active mobile phone number to use (not > > > sure if telegram is the same). > > > > > > I'm fine with IRC too. It's not broken, but unless you have your own > > > permanent IRC client instance somewhere it's not great. Having the > > > store and-forward done by someone else (unless you want to still do it > > > yourself) is nice. > > > > > > Wookey > > > > I agree. > > > > Importantly, Matrix is (1) federated, (2) can be bridged with other > > networks, eg IRC. > > > > (as well as being open and free). Its hard to see Signal inter-operating > > to others. As tech evolves, we need to stick to principles of being open > > in the sense of federation, not being centralized. > > There is the Debian Social [1] Matrix instance at > https://element.debian.social. You can sign in with Salsa. Many of the > Debian IRC channels are bridged and collected in the > #debian:matrix.debian.social space. > Nice Groeten Geert Stappers [1] https://wiki.debian.org/Teams/DebianSocial -- Silence is hard to parse signature.asc Description: PGP signature
Another workflow for Rust Was: Rust libraries left broken
Hello Jonas, Hello people in the CC, On Mon, Apr 11, 2022 at 12:34:47PM +0200, Jonas Smedegaard wrote: > Quoting Sylvestre Ledru (2022-04-11 09:34:48) > > Le 11/04/2022 à 01:14, Jonas Smedegaard a écrit : > > > Quoting Sylvestre Ledru (2022-04-10 22:15:47) > > >> Maybe you should join the team, commit there and follow the process > > >> for our packages? :) > > > > > > Thanks for the suggestion, but I decline the offer: > > > > > > I am not interested in joining a team where packages should be > > > tracked in one giant git repo. > > > > > > If I am mistaken and that's not a policy in the Rust team - or if > > > the team might consider changing that policy, then I would gladly > > > join. > > It is and it probably won't change (too hard)) > > > > I will then have to ask you to stop doing NMU without delays as it > > will make our life harder. :( > > Thanks, your kind request is duly noted. > > Rust team [discouraging nmudiff] and [not using our BTS], and leaving > packages [very broken], makes our lives harder as well. :-( > > > - Jonas > > [discourage nmudiff]: See https://bugs.debian.org/998347#28 > > [not using our BTS]: See https://bugs.debian.org/969609#10 > > [very broken]: Totally broken for months despite fix being simple > (and notably *not* needing to involve NEW queue): > * rust-rustls: 6 months FTBFS, https://bugs.debian.org/1007749 > * rust-sha-1: 16 months FTBFS, https://bugs.debian.org/1009123 > * rust-http: 4 months FTBFS, https://bugs.debian.org/988945 > Duly noted and in my very own works: Acknowledge Now that is expressed that things are NOT going smoothly, we should be alert that we NOT gonna fight with each other. Jonas, you have my permission to let it go. Jonas, you have my permission to let it go for now. Jonas, my actual request is that you notice that your report "Debian Rust packaging currently sub-optimal" has been seen. Then interpret it as "no need to add more fuel to the flame war". It is up to us for how long we let cool this down. The cooling down is important for getting a constructive mindset. As in "frustration will block finding a solution". I will leave this "as is" for the next few days. And after that continue with an old idea how to improve Debian Rust packaging. That will be at debian-r...@lists.debian.org I have set Reply-To for it. Groeten Geert Stappers DD -- Silence is hard to parse
Bug#992692: link
iHTH https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008652
Bug#1008652: mirrors must support also HTTPS in order to be considered official
Control: retitle -1 mirrors must support also HTTPS in order to be considered official > This is related to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992692 Quoting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992692#37 This change is more about recognizing HTTPS as the primary transport protocol for the modern Web, not sending mixed signals regarding the general security risks posed by plain HTTP when used for unrelated purposes, and no longer needing to repeatedly explain to users that Debian has gone to great lengths to implement package distribution security which doesn't really depend at all on transport layer encryption. Original Subject: mirrors must support HTTPS in order to be considered official should have been: mirrors must support also HTTPS in order to be considered official I have retitled this wishlist bugreport accordingly to make more clear that the wish is about **adding** another transport protocol, not about **switching** transport protocol. Groeten Geert Stappers -- Debian has gone to great lengths to implement package distribution security which doesn't really depend at all on transport layer encryption.
Re: access forbiden salsa.debian.org, Back in Business
On Tue, Mar 01, 2022 at 01:55:52PM +, Philip Wyett wrote: > On Tue, 2022-03-01 at 15:24 +0200, Jonathan Carter wrote: > > Hi Phil (and everyone) > > > > On 2022/03/01 15:10, Philip Wyett wrote: > > > Thank you for the terse response. The two examples i.e. micronews and the > > > infra list do not > > > sound > > > that this is scheduled work at all. Better communication from teams would > > > possibly give better > > > understanding and the patience of users/developers that is being asked > > > for. > > > > Our GitLab instance (Salsa), have fallen behind multiple versions. This > > is due to a bunch of different hurdles that all came with their own > > decisions (I'm going to urge the Salsa admins again to do a write-up > > about it). > > > > So what's happening now is point-to-point upgrades between all the > > GitLab versions needed on this upgrade path, along with the migrations > > between them (which are quite large, Salsa is one of the biggest GitLab > > instances out there). > > > > So while a huge amount of pent up maintenance is all happening at once > > now, at least regular updates (and security updates) will be able to run > > again on short cycles. > > > > (I hope salsa admins don't mind me posting this, but I hope it helps all > > our contributors better understand what's going on). > > > > On a practical note, please take note of any uploads you do during this > > downtime, and be sure to do a git push along with the tags when Salsa is > > back up again. > > > > -Jonathan > > > > Hi Jonathan, > > Many thanks for the update. I hope work progresses well and salsa is > available again soon post the > work that needs to be performed. > > Regards > > Phil > Yes, salsa is back. https://micronews.debian.org/2022/1646175793.html
Re: uscan roadmap
On Thu, Dec 02, 2021 at 11:36:08AM +0100, Yadd wrote: > On 02/12/2021 10:16, Yadd wrote: > > On 02/12/2021 00:34, Paul Wise wrote: > > > On Wed, 2021-12-01 at 12:53 +0100, Yadd wrote: > > > > > > > Personally I dislike redirectors. > > > > > > A redirector service is superior to including the redirector code > > > within uscan itself or within a debian/watch file, since when the > > > upstream website breaks the existing code, a service can be updated in > > > one place immediately, while uscan in Debian stable will be broken > > > until the next point release if it gets fixed at all and one in > > > debian/watch requires every package using the site to get updated. So true > > > > Yes but the redirector often responded with 500 codes > > Another idea to have a compromise: > * uscan is released with versioned schemes (GitHub.json, sf.json,...) > * when launched, it tries to download new version from a new Debian API >(static json files) >* if no response or no new version, uscan uses its own scheme or a > previously downloaded update (verifying signature) >* if a new version is available from new redirector: > * it verifies GPG signature of new scheme >* if not OK, it warns and uses cached scheme >* if OK, it stores it with signature in ~/.cache/uscan/schemes > > Then: > * no more redirector with an heavy load, but just some JSON schemes >statically stored > * uscan still works if Debian website doesn't respond > > What do you think about this idea? Way too optimistic :-) The original problem was (and is) dealing with various upstream websites. Putting a translator, a redirector, between uscan and a single upstream website solves the problem for that particular website. IMNSHO is building (hard to upgrade and distribute) "solutions" for redirectors with 500s or whatever error effort at the wrong place. Explaining to the user (us, debian maintainers) what is happing is a better approach. Especial when the redirector can explain the 500 is due problems with the actual upstream website. Groeten Geert Stappers -- Silence is hard to parse
Re: uscan roadmap
Summary: unhide redirectors On Wed, Dec 01, 2021 at 09:11:17AM +0100, Yadd wrote: > Hi, > > after few discussions with some devscripts maintainers, we decided to build > a new "version=5" format for debian/watch. > > Principles: > * keep compatibility with versions 3 and 4, no need to change all >debian/watch files > * new version 5 format using the same syntax than other debian/* files >(rfc822 + "# comments") > * no option renaming (becomes case-insensitive to be compliant with >all formats) > * Version 5: >* Main (first) paragraph contains "Version: 5" and optional options > that change default values for source-paragraph >* URL and regex are separated >* Some default values change. For example, `dversionmangle` default > value will be "auto" (drop +dfsg, ~ds,...), uversionmangle=s/-/~/g, > filenamemangle=s/.*?(\d[\d\.]*@ARCHIVE_EXT@)/@PACKAGE@-$1/... > > Example: > > Version: 5 > > > Of course, comments are welcome! I think the move from v4 to v5 is an excellent opportunity to express in the watch file that there is a dependency on a redirector. Example version=4 https://sf.net// -(.+)\.tar\.gz debian uupdate becomes something like Version: 5 Source: https://qa.debian.org/watch/sourceforge/ -(.+)\.tar\.gz debian uupdate And I think such change will allow removal of bare Disable all site specific special case code such as URL redirector uses and page content alterations. from the uscan code and uscan manual page (they are in /usr/bin/uscan ) The goal is to have documented that there are extra components being used. Avoiding nasty surprises. Groeten Geert Stappers P.S. Awareness of redirectors will get us more redirectors. Those redirectors will help us to prevent that `uscan` must get a javascript interpreter. -- Silence is hard to parse
Re: Future of /usr/bin/which in Debian?
On Wed, Aug 18, 2021 at 07:56:05PM +, Clint Adams wrote: > On Wed, Aug 18, 2021 at 09:48:29PM +0200, Geert Stappers wrote: > } } I'm happy to transition /usr/bin/which to alternatives > > Which alternatives would that be? > > I meant > > update-alternatives --install /usr/bin/which which /usr/bin/which.debianutils > 0 > > in postinst and so on so that FreeBSD which and GNU which and friends could > take over. Please do. Make such take over possible. It is what https://salsa.debian.org/debian/debianutils/-/merge_requests/6#note_242172 is asking for. Groeten Geert Stappers -- Silence is hard to parse
Re: Future of /usr/bin/which in Debian?
On Wed, Aug 18, 2021 at 06:53:45PM +, Clint Adams wrote: > > I'm happy to transition /usr/bin/which to alternatives Which alternatives would that be? | $ apt show alternatives | N: Unable to locate package alternatives | $ > if people are interested in packaging all of these. > Groeten Geert Stappers -- Silence is hard to parse
Re: merged /usr considered harmful
Summary: let go, let go On Sat, Jul 17, 2021 at 09:13:57PM +, Thorsten Glaser wrote: > > And no, I’m not going to embrace every unnecessary change thrown my way. None of us does embraces every unnecessary change. We all choose our battles wisely. > No; usrmerge is broken from the PoV of Debian’s package manager. > Running usrmerge breaks assumptions done by dpkg; you can probably > do it with RPM or something, but it’s not supported with dpkg. Hence a change. Groeten Geert Stappers -- Silence is hard to parse
Re: Reconsider sending ITP bugs to debian-devel: a new list?
On Mon, Jun 14, 2021 at 04:22:31PM +0200, Stephan Lachnit wrote: > On Fri, Jun 11, 2021 at 4:26 PM Steve McIntyre wrote: > > > > To be honest, I think if we did that we'd lose just about all the > > reviews that currently happen. The whole point of sending ITPs to > > d-devel is that they will be seen by a wider audience, but I can't see > > many signing up for YA mailing list for them. > > How about sending a digest of a potential debian-itp to d-d on a weekly basis? If, and only if, that gets implemented: * The burden of matching Subject: with subject of email * The burden of adding the correct BTS-number as email To address > I think we wouldn't lose any reviews with this, I would even go as far > and claim that there will be more reviews, since it's less of an > "annoyance" and more of a weekly "let's see what people are up to". I think we would lose many reviews with a "weekly digest". Groeten Geert Stappers -- Silence is hard to parse
Re: How to commit a new architecture like RISC-V
On Fri, May 21, 2021 at 09:07:10AM +0800, zhangjialing wrote: > 在 2021/5/20 下午5:42, Helmut Grohne 写道: > > Hi, > > > > On Thu, May 20, 2021 at 02:52:32PM +0800, zhangjialing wrote: > > > the upstream is not support now , the patch is in our local repository. > > I fear that this is a very bad basis to bootstrap Debian from. I > > strongly recommend deferring a Debian port and upstreaming first. > > Hi, > > I have known upstreaming first , I will make a plan for this debian port. OK > Please, when we upstreaming our patch , Is there a version limit for the > soft like gcc ,glibc New features (new architectures) are added to latest version. Talk and keep talking with upstream project members, become upstream project member. In general talk and keep talking with project members, become a project member. Express that you are stakeholder, express that that you are aware of the mutual benefit of having another instruction set architecture added. So yes, there is a limit for the software version of gcc and glibc. It most be recent. Groeten Geert Stappers -- Silence is hard to parse
Re: Cancel "culture" is a threat to Debian
> Cancel "culture" activists want Debian to sign a petition regarding > Richard Stallman's membership in the Board of Directors of the Free Software > Foundation. > > This is not our business. Debian has a mission, and matters of the membership > of other organisations is not our concern. Partly. We, Debian, must learn from it. Facts: * rms was kicked from FSF board * rms is back at FSF board To me it says: * There was a time that FSF did internal repairs * Current FSF is unaware of their stink We, Debian, do our internal repairs, we deal with errors[1], are aware of what our smell is and what our smell will be. I haven't checked yet all vote options. I will find an option like the membership of other organisations is not our concern or have to create such option. Note to all who think I should choose a side: It is about choosing whom to work with, not to judge with whom not. A better world starts from within. > All the best, > Dmitry Smirnov > GPG key : 4096R/52B6BBD953968D1B > > --- > The suppression of uncomfortable ideas may be common in religion and > politics, but it is not the path to knowledge; it has no place in the > endeavor of science. > -- Carl Sagan > Regards Geert Stappers [1] includes reference to a simular account name -- Silence is hard to parse signature.asc Description: PGP signature
Re: Anyone willing to package a new file browser?
On Mon, Mar 08, 2021 at 03:31:08AM +0200, _ wrote: > Hi, > I wrote a new file browser, I was wondering if anyone's willing to try > it out and/or package it for Debian? > The source code and how to build it: > https://github.com/f35f22fan/Cornus > Original poster is looking for https://wiki.debian.org/ITP Answering the question: Yes, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984757 Groeten Geert Stappers DD -- Silence is hard to parse
Re: New service: https://debuginfod.debian.net
On Sun, Feb 28, 2021 at 07:22:07AM +, Ian Campbell wrote: > On Sat, 2021-02-27 at 17:30 -0500, Sergio Durigan Junior wrote: > > I don't know if I understand the pushback I'm seeing > > against using a debconf question for this. > > FWIW I don't think I've read any actual pushback on that in this thread > although I can see how it might appear that way to another reader. I > took it as people offering possible alternatives or future extensions > -- certainly that was my intention once the intent to have a debconf > question was clear (which I tried to clarify but perhaps failed at). > When I said earlier "So long as it is opt-in at the gross level" I was > referring to the debconf being sufficient. Well spoken. It matches my point of view and my opinion. > I think (and I have inferred that you think) the need for discussion of > alternatives or future improvements isn't especially productive at the > current time so I won't prolong that aspect of the thread by replying > to the rest of your mail Matches the principle of "Those who do decide". It is the attitude that did bring us, Debian, so far. That it also did made us leaving network silence and other "good things", is something we have to deal with. Methods, ideas and opinions on the "how", please in a fresh thread. Groeten Geert Stappers -- Silence is hard to parse
Re: GSoC 2021
Executive summary: a re-transmit On Wed, Feb 03, 2021 at 02:12:56PM +0530, Aditya Pratap Singh wrote: > Hi, > I have not yet seen any GSoC announcement this year. > As far as I know the application period has started. I like https://lists.debian.org/debian-mentors/2021/02/msg00027.html > Will Debian participate this year? I don't know. But I think the question is Has Debian for the year 2021 tasks that do exist and have a mentor available for "Google Summer of Code"?? > Sorry if its just me who missed some announcement. Thanks for sparking the discussion. As in: No need to say sorry for missing announcement that missed their audience. > Kind regards > Aditya Groeten Geert Stappers -- Silence is hard to parse
Re: Making Debian available - Testing iso download
On Fri, Feb 05, 2021 at 04:21:42PM +, Paul Sutton wrote: > Would it be possible to make it easier to find the ISO for the next release It is work in progress and the process is called "Doing a release".
Re: Making Debian available, non-free promotor
On Thu, Jan 28, 2021 at 09:44:36AM +0200, Jonathan Carter wrote: > On 2021/01/28 01:49, Daniel S. wrote: > > The hope would be that, after collecting a 5 figure sum has been > > donated, paid developers work on freeing the most common firmware(s). > > If that was enough to free up firmware, we'd probably have figured out a > way to pay that right away without even spending time doing additional > fund raising. I do read that as "Lets figure out the other options" Regards Geert Stappers DD -- Silence is hard to parse
Re: Making Debian available
On Sat, Jan 23, 2021 at 04:30:00PM +0100, Pierre-Elliott Bécue wrote: > Le samedi 23 janvier 2021 à 16:23:47+0100, Marco d'Itri a écrit : > > On Jan 23, Pierre-Elliott Bécue wrote: > > > > > While I appreciate your point, and agree with the rationale behind it > > > (having something that works for very recent hardware would be good), I > > This is not about "very recent" hardware, it is really about "most > > hardware". > > > > > personally find the way you express it rude for those whose principle > > > are on the side of sticking to the philosophy of the project, which is > > > to provide Free Software. > > I do identify as somebody sticking to the philosophy of the project, > > which is to provide Free Software, as it was understood when I joined > > Debian 24 years ago. > > > > I still believe that advertising CD images which do not work for the > > vast majority of our users is self-inflicted harm which does not help > > anybody. > > I understand. We all understand it. Okay, most of us understand it. > But could you maybe consider telling it in a way that doesn't make us > look like we want to have a gap between our own members on each and > every topic please? Requests on how to tell about a gap, will NOT close that gap. Regards Geert Stappers -- Silence is hard to parse
Re: +1 (Re: Making Debian available)
On Sat, Jan 23, 2021 at 10:43:40AM +, Holger Levsen wrote: > On Sat, Jan 23, 2021 at 11:14:52AM +0100, Emanuele Rocca wrote: > > Having the option to opt-out firmware during the installation procedure > > seems reasonable to me, and I don't think anyone was suggesting > > otherwise. > > > > The situation we are in today is very different though: we build a > > Defective by Design image that fails to install Debian on lots of > > computers because it does not include the firmware most WiFi cards need > > to function. If we were to make a mistake and accidentally include such > > firmware, people would be able to use what we publish on www.debian.org > > under the large "Download" button to install Debian on their Thinkpads, > > and we would consider that a problem. That's insane. > > very well said, thank you! > Yes, we have to embrace firmware blobs. No for accepting Binary Large OBjects, but for accepting hardware. When we are not customers of hardware that "needs" blobs, we are not in a position to negotiation about it. Regards Geert Stappers -- Silence is hard to parse
Firmware awareness Was: Making Debian available
On Mon, Jan 18, 2021 at 04:35:01PM +, Steve McIntyre wrote: > Marc Haber wrote: > > > >I was not aware of that feature. It is good to have that, but I would > >be embarrassed to seriously suggest this way because we can't manage > >to get WLAN working in the installer for political reasons. > > Are we seriously just going to describe our Free Software goals as > "political reasons"? Should we just abandon them? Those are two rhetorical questions. We should find a better way to deal with firmware blobs. (Surely not abandon the reasons why we have this project.) We, the Debian project, are fully aware of how odd firmware blobs are. What to do with the awareness is yet unknown. Regards Geert Stappers -- Silence is hard to parse
Re: Making Debian available
On Sat, Jan 16, 2021 at 03:10:46AM +0500, Andrey Rahmatullin wrote: > On Fri, Jan 15, 2021 at 09:19:37PM +0100, Marc Haber wrote: > > On Fri, 15 Jan 2021 21:45:35 +0500, Andrey Rahmatullin wrote: > > >We already tell people to enable non-free > > >and check everything they install as that's the only option we provide. > > > > And those people usually react by taking their choice and install ... > > > > > > ... a different distribution. > > > > Do we want this? > > Yes, hardcore FSF fans shouldn't influence our distribution choices. ? Regards Geert Stappers -- Silence is hard to parse
Re: Making Debian available, non-free promotor
On Tue, Jan 12, 2021 at 05:14:14PM +0100, Sven Joachim wrote: > On 2021-01-12 16:36 +0100, Geert Stappers wrote: > > On Tue, Jan 12, 2021 at 02:48:22PM +, Dan Pal wrote: > >> Hello Debian Developers, > > > > Hello World, > > > > > >> I am writing to you from my Debian-Buster 10.6 laptop – that used > >> to be a Windows 10 laptop. I would not be using Debian at all except I > >> was able to find a dvd version at debian.org to install. I couldn’t > >> install from a net install version because of my wireless chipset not > >> being supported directly by Debian. The current policy of hiding other > >> versions of Debian is limiting the adoption of your OS by people like > >> me who are interested in moving from Windows 10. > > > > Seen the "I think it could be better", not yet seen the "how" > > > > > > Please elaborate the improvement. > > Provide a way to discover the working netinst with non-free firmware, > right now it seems to be impossible to find. Ah, yes I also wonder how much the world will improve if non-free would be split in non-free and non-free-firmware. Currently is non free firmware a hugh promoter of non-free in /etc/apt/sources.list > The official netinst image advertised on the homepage is for servers and > virtual machines only. How is an average user of Windows or even other > GNU/Linux distributions supposed to know that official Debian images do > not offer network access during installation on desktops and laptops? Regards Geert Stappers -- Silence is hard to parse
Re: Making Debian available
On Tue, Jan 12, 2021 at 02:48:22PM +, Dan Pal wrote: > Hello Debian Developers, Hello World, > I am writing to you from my Debian-Buster 10.6 laptop – that used > to be a Windows 10 laptop. I would not be using Debian at all except I > was able to find a dvd version at debian.org to install. I couldn’t > install from a net install version because of my wireless chipset not > being supported directly by Debian. The current policy of hiding other > versions of Debian is limiting the adoption of your OS by people like > me who are interested in moving from Windows 10. Seen the "I think it could be better", not yet seen the "how" Please elaborate the improvement. > Sincerely, > Dan Regards Geert Stappers -- Silence is hard to parse
Re: one more for the road
On Wed, Dec 23, 2020 at 08:08:47PM +0100, Marc Haber wrote: > On Wed, 23 Dec 2020 19:43:18 +0100, Richard wrote: > > ... But I am sorry I again start, I am still >: and feel being a > > target but that is a outdated computer so there is something wrong > > with my first post too. Let go, let go > Still, nobody knows what your actual problem is. Aim for common interests > Are you trolling? In case of doubt on trolls: Stop feeding them Regards Geert Stappers @Richard: Heb je ergens begin januari een mogelijkheid om naar https://jitsi.debian.social/VertelEensWatErSpeelt te kunnen? Die ja-nee-vraag is inderdaad een openingsvraag. -- Silence is hard to parse
Re: im am fed up and we go beyond it
On Wed, Dec 23, 2020 at 06:24:15AM +0100, Richard wrote: > On di, 2020-12-22 at 23:28 -0500, Calum McConnell wrote: > > On Tue, 2020-12-22 at 21:34 +0100, Richard wrote: > > > why no respond >: > > > > Sir, > > This is a volunteer organization. Anyone and everyone here contributes > > soley because they feel like it. You have not paid us anything, > > therefore, we are not beholden to give you anything. That includes a > > response to your email. If you want productive responses, I recommend you > > glance through the code of conduct [1] > > > > That being said, we will try to respond to everything, even three word > > messages that tell us nothing about their problem. However, I could not > > find any mail from you, at all. Are you sure your email client is set up > > correctly? > > > > [1]: https://www.debian.org/MailingLists/#codeofconduct > > > I have mailed a few official e-mails and some persons (surname@debian) > i have a request Vertel gewoon wat je verzoek is. Doe moeite voor wat je wilt. Als wilt plassen, dat mag, ga gewoon naar het toilet. Echter niet zeiken. Inderdaad Richard, het is je gelukt om wat negatieve energie los te krijgen. Weet dat het aan jezelf is om met goede vragen te komen. In http://www.catb.org/~esr/faqs/smart-questions.html de lange versie. Of ik boos ben? Dat is niet belangrijk. Belangrijk is dat wij onze gesamenlijk belangen vinden. Summary: Get beyond whining Regards Geert Stappers DD P.S. An advice: Make a fresh start, assume this email thread never happend -- Silence is hard to parse signature.asc Description: PGP signature
Re: CentOS and Debian/Ubuntu release cycles
On Thu, Dec 10, 2020 at 05:16:28PM +0100, Marco d'Itri wrote: > On Dec 10, Paul Wise wrote: > > Both of these situations sound like things that should get solved by > > rewriting the vendor/O-O-T code and including it in mainline > > Linux/etc, is there any chance of that happening? Or alternatively, > The Fibre Channel drivers ARE all upstreamed, it's just that the inbox > drivers (i.e. distributed with the OS, in vendors speak) are not > qualified to receive support (and may be buggy, even in RHEL). > Storage vendors provide a support matrix with supported releases of the > storage firmware, FC switches firmware, network adapter firmware, OS and > OS driver. Anything else may not receive support. > > > for significant future hardware acquisitions, require mainline support > > before purchase. > Obviously, but I am not aware of any such FC/FCoE hardware (not just the > network adapters, but also the storages). Acknowledge on that problem. Do know that it can and must be solved by wallet. So do talk with your purchase department. Regards Geert Stappers -- Silence is hard to parse
Re: ik wil meedoen en een antwoord van een menselijke e-mail accoutn ?
Lingua franca after the dutch text On Sun, Nov 22, 2020 at 12:13:34AM +0100, Richard wrote: > Haloo Debian, Hallo Richard, > Ik heb wat e-mails verstuur den wil nu eindelijjk meedoen maar dan moet > iemand wel reageren op mijn e-mails? Ja, aansluiting vinden is uitdagend. Wat tips: * Heb iets wat je leuk/belangrijk/goed/interresant vind * Maak dat kenbaar * Kijk wat er gebeurd * Ga er vanuit dat er meerdere pogingen nodig zijn * Er is een nederlandstalige mailinglist debian-user-du...@lists.debian.org * Mailinglist debian-events...@lists.debian.org is dat ook wel * Engels is echter de gangbare taal in Debian * Ben ge-aboneerd op de ML waar je berichten naar toe stuurt * Weet dat jij zelf moet afhalen, verwacht niet dat het je gebracht wordt * Ga voor wisselwerking, dus geven en nemen English: | } I want to get involved, but I feel ignored | Advice on how to get forward > Groeten, > Richard Waterbeek > Nederland Regards Geert Stappers Internet -- Silence is hard to parse
Re: Split Packages files based on new section "buildlibs"
On Wed, Nov 11, 2020 at 02:26:55PM +0100, Matthias Klose wrote: > On 11/10/20 10:51 PM, Joerg Jaspert wrote: > > On 15948 March 1977, Paul Wise wrote: > > > >> Does this include the -dev packages for C/etc libraries? > > > > No. > > > >> I guess it also applies to Haskell and other statically-linked languages. > >> https://wiki.debian.org/StaticLinking > > > > StaticLinking itself is not enough. This is about languages where the actual > > development in it is discouraged from doing with the debian packaged stuff. > > Where you do not go "I need lib XY, i install libxy-perl/libxy-dev/whatever > > the > > name" and hack around using it. But "Oh, i want to hack on foo, i go get > > foo/cargo .../whateverthetool" and the debian package only ever comes in > > play if > > you do build debian packages using it. > > If you ask some upstreams of Python based software, their recommendation would > be to use pip, and probably conda (a cross OS distribution focusing on Python) > to do upstream development. If you ask casual users, you probably will get > another answer. > > Same thing probably for Java libraries. I don't know anybody who would do > development using the Debian packaged libraries. > > > > >>> The current proposal is to reduce the main Packages.xz files size by > >>> splitting[4] out all of the packages that are not intended for users, > >>> writing those into an own file. Those packages would have a section of > >>> "buildlibs", independent of their other properties. > >> Should (almost?) everything in the existing libdevel section move to > >> the new buildlibs section? > > > > No, if so we would have split that section out. > > Reducing the size of the index file is a technical issue inside Debian, and > relating that to > > """ > languages where the actual development in it is discouraged > from doing with the debian packaged stuff > """ > > seems to be wrong, as any upstream eco system providing their own environment > for development and distribution would need to move to this section. I don't > think the reference to upstreams doesn't help with the definition of the new > section. The thing we should aim for, the thing I'm aiming for, is that software developed in any programming language can be distributed by Debian. User point of view: `apt install foo` Debian policy p.o.v. `apt-get source foo` > Matthias > Regards Geert Stappers -- Silence is hard to parse signature.asc Description: PGP signature
Re: NEW queue almost empty
On Sun, Nov 08, 2020 at 10:18:47PM +0100, Jérémy Lal wrote: > Le dim. 8 nov. 2020 à 21:48, Pierre-Elliott Bécue a écrit : > > Le lundi 02 novembre 2020 à 13:37:16+0100, Christian Kastner a écrit : > > > The NEW queue length is down a single digit, from ~500 not all too long > > > ago. That's an amazing effort by ftp-master that must have consumed a > > > *lot* of energy. > > > > > > THANK YOU! > > > > Agreed, that's a huge work done, thanks to all FTP Masters! > > > Who uses ftp nowadays ? Nowadays means FTP Filtering The Packages. Regards Geert Stappers Very happy with the nice reminder on the upcoming freeze -- Silence is hard to parse
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On Sun, Sep 13, 2020 at 10:32:36AM -0700, Sean Whitton wrote: > Hello, > > > On Sat, 12 Sep 2020, Sean Whitton wrote: > >> There are arguments both ways here but as you're the person driving > >> this, I'm still keen to hear more from you about why debian/unstable is > >> to be preferred over debian/sid giving the existing convention > >> established by dgit. Thanks. > > > > I don't have figures about their respective usage and I have no time to > > look into collecting such statictics. However I have been convinced by > > Simon Mc Vittie's request to document some sort of preference. > > > > debian/unstable better matches what we put in the changelog: we > > put unstable for upload to the development release (and we put a codename > > for stable uploads). In https://lists.debian.org/msgid-search/871rjnu3r9@hope.eyrie.org is that also said by Russ Allbery. > > debian/unstable is more expressive than debian/sid for persons who > > are not very familiar with the debian release naming scheme. > > Okay, thanks. Yes, we are closer to consensus. Other warm feeling I have is that this discussion learnt me that DEP-14 was originally written with Upstream in mind. Regards Geert Stappers DD -- Silence is hard to parse signature.asc Description: PGP signature
Re: Nitrokey for DDs
On Wed, Sep 09, 2020 at 09:44:52PM +0200, Zlatan Todorić wrote: > Hi Jonas, Hello World, > On 9/9/20 9:32 PM, Jonas Smedegaard wrote: > > Quoting Zlatan Todorić (2020-09-09 20:21:18) > > > On 9/9/20 7:48 PM, jathan wrote: > > > > > https://github.com/nitrokey > > > > I find interesting and very nice Nitrokey as they are making their > > > > products with Free Software! I think your proposal is good. Do you > > > > know if the hardware of their keys is Open Hardware too? Anyway, > > > > consider myself to help them keep growing as independent FOSS > > > > vendor. Thanks for sharing this! > > > I snipped rest of my mail but you can see the part where I left the > > > github page and there they also publish their hardware schematics. :) > > We all got different skills. Personally, after trying with several > > products to sift through git repositories for schematics, I have learned > > that I cannot reliably assess if those are enough to build such hardware > > or it only covers a subset or an outdated revision or maybe is missing > > BOM or whatever. > > Time for some sort Debian Hardware Team and gather there open source > hardware (Free hardware) experts so they can compile list of the most > acceptable hardware to Debian standards and also (don't yell on me!) maybe > fund some Debian hardware experiments /o\. It would be cool to have Debian > Developers working/collaborating in the world of hardware (bridging us to > one more field/community). Do know there are hardware designers / manufactors / vendors who already do sell libre products. > Z (throwing random ideas) Challenge: wallet voting Regards Geert Stappers -- Silence is hard to parse
Re: Lenovo discount portal update (and a few other things)
On Thu, Sep 03, 2020 at 12:11:02AM +0200, Marco d'Itri wrote: > On Sep 02, Mark Pearson wrote: > > > You should just be able to register with your debian.org email address to > > get the discount on any Lenovo equipment. Do let me know if any problems. > This is great news, even if I do not live in the USA so this is not > relevant for me at this time. > But you should be aware that not all developers choose to enable their > debian.org email address, so given time it would be useful to have an > alternative authorization method. Such as? Regards Geert Stappers P.S. Nice to see another reward to @debian.org people -- Silence is hard to parse
Re: RFC: Final update of DEP-14 on naming of git packaging branches
On Sun, Aug 30, 2020 at 02:52:33PM -0400, The Wanderer wrote: > On 2020-08-30 at 14:46, Richard Laager wrote: > > On 8/30/20 12:02 PM, Sean Whitton wrote: > >> On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote: > >>> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn > >>> index 0316fe1..beb96ea 100644 > >>> --- a/web/deps/dep14.mdwn > >>> +++ b/web/deps/dep14.mdwn > >>> +In the interest of homogeneity and of clarity, we recommend the use of > >>> +`debian/unstable` over `debian/sid` as it better conveys its special > >>> nature > >>> +as opposed to other branches named after codenames which are used for > >>> +stable releases. > >> > >> I think we should recommend debian/sid because for some years dgit > >> has been generating branches called dgit/sid. I think it would > >> smooth the integration between branches on salsa and branches on > >> dgit.debian.org if both always used codenames. Yes, DEP-14 is about providing guidelines for this. And DEP-14 guides the URL for `debcheckout` > > Using debian/sid makes the branch name inconsistent with > > debian/changelog, which traditionally uses "unstable" not "sid". There no need to have consistency between a git branch name and debian/changelog saying where to upload. > > It also makes debian/experimental an outlier that cannot be made > > consistent (because there is no character code name for experimental > > AFAIK). > > I thought the same at one point, but in fact, there is: it's called > rc-buggy. > > https://wiki.debian.org/DebianReleases#Codenames > http://ftp.debian.org/debian/dists/rc-buggy/ > Learn from bikeshedding that it is just bikeshedding. Regards Geert Stappers -- Silence is hard to parse
Re: Accepting / adopting DEP-14
On Wed, Aug 26, 2020 at 06:08:17PM +0100, Simon McVittie wrote: > On Wed, 26 Aug 2020 at 16:00:02 +0200, Jonas Smedegaard wrote: } } [ ... good input ... ] How to go from good input to accepting DEP-14 ?
Accepting / adopting DEP-14
Hi, The good things of https://dep-team.pages.debian.net/deps/dep14/ are in use. But https://dep-team.pages.debian.net/deps/dep14/ it self looks abandonned. What is needed to official accept DEP-14? (and to give https://dep-team.pages.debian.net/deps/dep14/ status "adopted") Groeten Geert Stappers -- Silence is hard to parse
Re: Why Vcs-* fields are not at least recommended ?
On Wed, Aug 19, 2020 at 02:18:08AM +0500, Andrey Rahmatullin wrote: > On Tue, Aug 18, 2020 at 11:10:04PM +0200, Alexis Murzeau wrote: > > I'm wondering why Vcs-* fields in debian/control (Vcs-Browser and/or > > Vcs-) > > are not recommended (or maybe even strongly recommended) ? (I mean here > > that I think > > having Vcs-* fields should be recommended for active packages) > They are just information fields. You cannot fill them if you aren't using a > VCS. > And we cannot recommend using a VCS because we don't usually recommend > workflows. > > > I acknowledge that previously, packages might not have been developed using > > a VCS as said in the policy. But I think now most packages have a VCS where > > it is developed. > I'm sure (almost) all of these packages already have Vcs-* tags. > > > Also, I see some orphaned packages in the QA group now actively maintained > > without VCS, which seems counterproductive if someone else wants to > > contribute > > too. > > In that case, this would be almost like a NMU I guess, but against an > > "non official maintainer" with manual merges (or lost changes). > > > > Or maybe orphaned package with QA upload are not supposed to be always > > collaboratively maintained ? (I'm new to these concepts, but to me the > > response to this should be "no"). > I don't think anything is "supposed" here. We don't recommend workflows > and if you need to make just one upload for an orphaned package you don't > need to touch any VCS. And for packages without a repo somebody would need > to create one which is extra work when you need to make just one upload. Please, pretty please, make `debcheckout ` possible Groeten Geert Stappers DD -- Silence is hard to parse
Re: Proposal: Allowing access to dmesg for users in group adm
On Mon, Aug 17, 2020 at 03:50:37PM +1200, Matthew Ruffell wrote: > Hello! > > I am currently working on a downstream effort to get > CONFIG_SECURITY_DMESG_RESTRICT enabled in Ubuntu, and I would like to see if > the Debian community is interested in carrying some of my proposed patches to > Ubuntu. > > Debian already has CONFIG_SECURITY_DMESG_RESTRICT enabled by default since > Stretch, but the dmesg command is restricted to superuser only. This is > inconsistent with regular logging, which is only restricted to users in group > "adm". > > For example, on a fresh Debian Buster system: > > $ head -1 /etc/os-release > PRETTY_NAME="Debian GNU/Linux 10 (buster)" > > DMESG_RESTRICT is enabled, and my user is in group adm: > > $ grep -Rin "CONFIG_SECURITY_DMESG_RESTRICT" > /boot/config-4.19.0-10-cloud-amd64 > 3130:CONFIG_SECURITY_DMESG_RESTRICT=y > $ groups > mruffell adm dip video plugdev > > Permissions for kern.log and syslog are for members of adm: > > $ ls -l /var/log/kern.log > -rw-r- 1 root adm 39414 Aug 11 21:44 /var/log/kern.log > $ ls -l /var/log/syslog > -rw-r- 1 root adm 60744 Aug 11 21:56 /var/log/syslog > > I can read /var/log/kern.log and journalctl: > > $ head -2 /var/log/kern.log > Aug 11 21:44:44 debian kernel: [0.00] Linux version > 4.19.0-10-cloud-amd64 (debian-kernel at lists.debian.org) (gcc version 8.3.0 > (Debian 8.3.0-6)) #1 SMP Debian 4.19.132-1 (2020-07-24) > Aug 11 21:44:44 debian kernel: [0.00] Command line: > BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-cloud-amd64 > root=UUID=fb69ad1f-43c0-40a4-8ec0-bb07f1175c82 ro console=tty0 > console=ttyS0,115200 earlyprintk=ttyS0,115200 elevator=noop > scsi_mod.use_blk_mq=Y > > $ journalctl -t kernel | head -3 > -- Logs begin at Tue 2020-08-11 21:44:43 UTC, end at Tue 2020-08-11 22:12:30 > UTC. -- > Aug 11 21:44:43 debian kernel: Linux version 4.19.0-10-cloud-amd64 > (debian-kernel at lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 > SMP Debian 4.19.132-1 (2020-07-24) > Aug 11 21:44:43 debian kernel: Command line: > BOOT_IMAGE=/boot/vmlinuz-4.19.0-10-cloud-amd64 > root=UUID=fb69ad1f-43c0-40a4-8ec0-bb07f1175c82 ro console=tty0 > console=ttyS0,115200 earlyprintk=ttyS0,115200 elevator=noop > scsi_mod.use_blk_mq=Y > > And yet, I cannot access dmesg: > > $ dmesg > dmesg: read kernel buffer failed: Operation not permitted > $ ls -l /bin/dmesg > -rwxr-xr-x 1 root root 84288 Jan 10 2019 /bin/dmesg > > Users on Ubuntu are accustomed to running dmesg without any permissions, which > is why my downstream proposal to Ubuntu contained the following: > > I propose that we restrict access to dmesg to users in group 'adm' like so: > > 1) CONFIG_SECURITY_DMESG_RESTRICT=y in the kernel. > 2) Following changes to /bin/dmesg permissions in package 'util-linux' > - Ownership changes to root:adm > - Permissions changed to 0750 (-rwxr-x---) > - Add cap_syslog capability to binary. > 3) Add a commented out '# kernel.dmesg_restrict = 0' to >/etc/sysctl.d/10-kernel-hardening.conf > > You can read my original proposal on ubuntu-devel if you are interested: > https://lists.ubuntu.com/archives/ubuntu-devel/2020-June/041063.html > > Would the Debian community also be interested in the changes to the dmesg > binary in package util-linux? > > An example debdiff of the suggested changes which implement 2) is below: > https://launchpadlibrarian.net/492806625/lp1886112_util-linux_groovy.debdiff > > This would allow any user in group adm to be able to run dmesg without > becoming superuser, and see the same information already available in > /var/log/kern.log, /var/log/syslog and journalctl. Correct. > Please let me know if you are interested, Yes I'm interested in this feature > as it enhances user experience when running dmesg, Yes, it does feel strange to prefix a readonly actio as dmesg with sudo. > and there would be less delta between Debian and Ubuntu > util-linux packages to maintain. That is a nice extra > Thanks, > Matthew Ruffell Groeten Geert Stappers DD -- Silence is hard to parse
Re: The "which -s" flag
On Fri, Aug 14, 2020 at 12:55:03AM +0200, Erik Gustafsson wrote: > Hi! > > The "which" command is part of debianutils. On BSD and Mac, this command on > Mac/BSD has a -s flag, for silent, when used it does not print, just return > 0 if program found in $PATH or 1 otherwise. See man-page for FreeBSD > https://www.freebsd.org/cgi/man.cgi?which(1) > > This "which" is heavily used at the company where I work, for java > development etc like > which -s java || echo "You have to install java to run this program" > > We have many shellscripts using this, but unfortunately they don't > work on GNU/Linux, only on Mac and BSD. > > The current version of "which" supplied with Debian is written in > shellscript > https://salsa.debian.org/debian/debianutils/blob/master/which > > To make my Debian installation compatible with "which -s" I have made a > merge request for this > https://salsa.debian.org/debian/debianutils/-/merge_requests/6/diffs Looks good to me (and also told that to Salsa) > How to proceed to get the Merge request reviewed? You are taking the right approach: Just do Now comes a challenging part: Give time to others to respond > I have never contributed to Debian before, but I am happy to do it :) Nice, you started > Best regards, > -Erik Regards Geert Stappers DD P.S. Welcome -- Silence is hard to parse signature.asc Description: PGP signature
Re: rust-dbus_0.8.2-3_amd64.changes REJECTED
Hi debian-devel, Summary: Team work for the win On Sun, Aug 09, 2020 at 04:16:07PM +0200, Andrej Shadura wrote: > On Sun, 9 Aug 2020, at 16:10, Bastian Blank wrote: > > > > REJECT > > > > #945542 > > > > > > > > === > > > > Please feel free to respond to this email if you don't understand why > > your files were rejected, or if you upload new files which address our > > concerns. > > > > > > Bastian, > > I'm curious why do you think a discussion in progress is a good > reason enough to block my work with no actual objections to the > package contents? > > I've waited for this package to pass a review for so long > and all I get is a REJECTED? > The clue '#945542' and "discussion in progress" is most like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945542#94 It has On Sat 2019-11-30 12:15:55 +0100, Bastian Blank wrote: > This problem is already listed since a long time in > https://ftp-master.debian.org/REJECT-FAQ.html. But reading this page, the closest thing i can find is its description of "Package Split", which reads: >>> You split a package too much or in a broken way. Well, broken or too >>> much is a wide definition, so this is a case-by-case thing, but you >>> should really think about a split before you do it. For example it >>> doesn't make any sense to split a 50k arch:all package from a 250k >>> arch:any one. Or splitting a package for only one file, depending on >>> the main package. Yes, big dependency chains can be a reason. Or big >>> documentation split into one -doc package. The point there is big. Bastian, if you meant something else, please correct me here! Then eight months past. How can we continue with where the november post is about: rust software to work in a well-established way in Debian ? Regards Geert Stappers DD -- Silence is hard to parse
Bug#837606: closed by Ansgar (Re: general: system freeze)
On Tue, Jul 28, 2020 at 04:06:13PM +0200, Rouven-Matthias Müller wrote: > [ ... ] Interesting, that nobody ever started to fix this problem. This is a little story about four people named Everybody, Somebody, Anybody, and Nobody. There was an important job to be done and Everybody was sure that Somebody would do it. Anybody could have done it, but Nobody did it. Somebody got angry about that because it was Everybody's job. Everybody thought that Anybody could do it, but Nobody realized that Everybody wouldn't do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done > have a good one. Thanks Regards Geert Stappers -- Silence is hard to parse
Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
On Sun, Jul 12, 2020 at 12:34:32PM +0500, Andrey Rahmatullin wrote: > On Sun, Jul 12, 2020 at 02:02:50AM +0200, Jonas Smedegaard wrote: > > > > Difficult when network-manager depends (not recommends) wpa-supplicant: > > > > https://bugs.debian.org/919619 > > > That Depends is not a problem. > > > > Yes a problem, but not a unsurmountable one: You can... > > > > a) pollute your Debian system using equivs, or > > > > b) install the dependency but then disable the daemon > You still need manual action to use iwd, so disabling wpa-supplicant is > just another command. > > > > -- > WBR, wRAR FWIW I think that Andrey is happy with a disabled wpa-supplicant and that Jonas is right for asking wpa-supplicant not required by network-manager. Groeten Geert Stappers -- Silence is hard to parse
Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
On Sun, Jul 12, 2020 at 01:21:22AM +0500, Andrey Rahmatullin wrote: > On Sat, Jul 11, 2020 at 10:08:11PM +0200, Jonas Smedegaard wrote: > > > (Way more people should switch from wpa_supplicant to iwd.) > > > > Difficult when network-manager depends (not recommends) wpa-supplicant: > > https://bugs.debian.org/919619 > That Depends is not a problem. Please elaborate how a Depends is not a problem for a switch. @marco: Thanks for telling there is `iwd`. $ apt show iwd 2> /dev/null | sed --silent '/^Description/,$p' Description: wireless daemon for Linux Minimalistic wireless daemon that uses modern Linux interfaces like cfg80211 and nl80211 (netlink). The daemon provides a D-Bus API. . The daemon can be controlled from the command line with the included iwctl client utility. . The included iwmon utility can be used to monitor the 802.11 subsystem generic netlink commands and events. It uses the nlmon kernel driver from Linux 3.10 and later. Groeten Geert Stappers -- Silence is hard to parse
Re: debdocker - A Debian docker-based personal builder
On Sun, Jun 28, 2020 at 08:29:22AM +0300, Tzafrir Cohen wrote: > On 27/06/2020 14:52, Mo Zhou wrote: > > Hi Samo, > > > > I'm insterested in its differences compared to the following existing > > docker-based builders: > > > > 1. debocker https://people.debian.org/~tomasz/debocker.html > > 2. whalebuilder https://www.uhoreg.ca/programming/debian/whalebuilder > > > > And there is a systemd-nspawn-based builder too: > > 3. debspawn https://github.com/lkorigin/debspawn > > There is also the recent ITP of due: > https://bugs.debian.org/961371 > that is a docker builder (Debian packages, or more generic) > Qouting that Intent To Package, ITP: * Package name: due Programming Lang: Bash Description : Wrapper tool to create and run Docker container software build environments. Dedicated User Environment (DUE) is a framework for creating preconfigured build/development environments in Docker containers. It serves two primary purposes: 1 - Maintains configurations for creating Docker images for any build environment, using any architecture of any Debian based release it can find an image for. For example, the Open Network Install Environment (https://github.com/opencomputeproject/onie) currently builds on Debian 8 and 9, but requires some Backports packages, and a program that isn't packaged for Debian. DUE maintains a configuration to get all of that added when the Docker image is created so ONIE can 'just build'. Apart from not requiring the end user to have to configure the build environment, it also allows all developers to use the same build environment when debugging - regardless of where they happen to be. 2 - It goes beyond 'just using a Dockerfile' by using a launcher application that supplies runtime configuration to Docker for the Docker images it has created. Apart from reducing typing and being smart about the containers that it runs (ex: containers building Debian packages mount the host directory _above_ the build directory so the resulting .debs aren't stored in the container), DUE preserves the user's identity in the container by creating an account for them with their user ID, and mounting their home directory so they can access their .config files. This creates a less intrusive development environment when the user is in a build/test/debug cycle. While the above are the most important features DUE provides, there are a lot more ways it makes using different development configurations easier, which are documented in the Readme.md (https://github.com/CumulusNetworks/DUE/blob/master/README.md) Regards Geert Stappers -- Silence is hard to parse
Re: debdocker - A Debian docker-based personal builder
On Sat, Jun 27, 2020 at 10:11:20PM +0200, Samo Pogačnik wrote: > Dne 27.06.2020 (sob) ob 19:43 +0200 je Johannes Schauer napisal(a): FWIW I didn't yet get that posting on this mailinglist. > > Quoting Samo Pogačnik (2020-06-27 19:01:57) > > > Dne 27.06.2020 (sob) ob 13:44 +0200 je Philipp Hahn napisal(a): > > > > I think there also was a discussion to include Docker support into > > > > sbuild, which would allow autopkgtest to use that interface. > > > > Yes, this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867176 > > > > > > <https://wiki.debian.org/SystemBuildTools> also list several other tools > > > > > > > > So please clarify why we need yet another tool and what are the benefits > > > > of your tool compared to the other ones already existing. Not only for > > > > us Debian Developers, but also in the package description for all other > > > > users looking for the right solution for their problem. Thanks. > > > > > > I can not really say what are the benefits of my tool since i do not know > > > other tools well. > > > > I think before starting to write any software, you should do exactly that: > > perform a review of what already exists, so that you can point out which > > problem your software is solving that existing software is not capable of. > > Otherwise, it's easy to fall into the NIH trap. And maybe there already > > exists > > some software which does 90% of what you want to do so that you don't even > > have > > to spend much work anymore. > > > > > It is good to have more tools available, at least until all use- > > > cases float out and get covered by the ultimate tool or a set of tools. > > > > Maybe, but that's not what is happening. Including your tool we now have > > *five* > > different "build packages with docker" applications. But with sbuild and > > pbuilder we already have had tried and battle tested tools for package > > building > > for *decades* and we already know which interface we need. Those tools just > > need to have the additional backend. But instead of somebody maintaining a > > docker backend for an existing packaging tool, we now have the fifth > > iteration > > of somebody writing yet another interface for something that already has had > > an > > interface for decades. > > > > I cannot apply the sbuild patch for docker support in #867176 for docker > > support myself because I never used docker in my life. But sbuild is team > > maintained and whoever wants a "build packages inside docker" tool can > > simply > > join the team and maintain the sbuild docker backend there. Or maybe even > > add > > a > > docker backend to autopkgtest so that "use docker for X" can even be added > > to > > more stuff automatically because autopkgtest provides a unified interfaces > > to > > many virtualization backends. > > > > I cannot tell any volunteer what to do with their free time but as you > > probably > > can see I'm quite a bit frustrated how much work is put into writing yet > > another (now the fifth) iteration of "build packages inside a docker > > container" > > without somebody leaving the NIH bubble and adding docker support to > > existing > > tools like sbuild, pbuilder or autopkgtest... > > > > Sorry for the rant. I know that it's not helping my cause. > > Hi Johannes, Hi Mailinglist, > thank you for all your comments and for pointing out the efforts with > 'sbuild'. > I agree with everything you said, however imho it is not always the whole > truth. > For example most of our beloved OS is a result of yet another sw for someone's > need. There is almost no SW segment that would not provide at least two > implementations of almost the same thing. In my case i spent quite some time > looking for a container based builder and checking, if the main builders > 'pbuilder' and 'sbuild' could use containers instead of chroot - > unsuccessfully. > After too much time "wasted", i end up writing 'debdocker', which anyone could > use (hence these posts). I would suggest you also try it as a sandbox for a > simple/sample docker usage. > > Regarding 'sbuild' docker backend, i would gladly try to help, however i would > probably need some guidance. After a quick look at #867176, there is an > 'sbuild' > patch available, but you are also talking about 'autopkgtest'. What exactly > needs to be done regarding the patch? Yes, please pursuit that challenge. Groeten Geert Stappers -- Silence is hard to parse
Re: local repostory doesn't show up (synaptic or apt)
On Sat, Jun 13, 2020 at 05:20:39PM +0200, Andreas Benzler wrote: > Total frustrated again with debian > (because it works on centos/fedora on first touch): > > /etc/apt/sources.list.d/local.list > deb [trusted=yes] file:/srv/repo/buster/ buster main > > --- > reprepro -b . includedeb buster /home/andy/dev/Xorg-1.19/1.19.7/*.deb > > /srv/repo/buster# find . > . > ./pool > ./pool/main > ./pool/main/x > ./pool/main/x/xorg-server > ./pool/main/x/xorg-server/xserver-common_1.19.7-1+deb10u1_all.deb > ./pool/main/x/xorg-server/xdmx_1.19.7-1+deb10u1_amd64.deb > ./pool/main/x/xorg-server/xserver-xorg-core-dbgsym_1.19.7-1+deb10u1_amd64.deb > ./pool/main/x/xorg-server/xserver-xorg-core_1.19.7-1+deb10u1_amd64.deb > ./pool/main/x/xorg-server/xdmx-tools_1.19.7-1+deb10u1_amd64.deb > ./pool/main/x/xorg-server/xnest_1.19.7-1+deb10u1_amd64.deb > ./pool/main/x/xorg-server/xorg-server-source_1.19.7-1+deb10u1_all.deb > ./pool/main/x/xorg-server/xwayland_1.19.7-1+deb10u1_amd64.deb > ./pool/main/x/xorg-server/xvfb_1.19.7-1+deb10u1_amd64.deb > ./pool/main/x/xorg-server/xserver-xorg-dev_1.19.7-1+deb10u1_amd64.deb > ./pool/main/x/xorg-server/xserver-xephyr_1.19.7-1+deb10u1_amd64.deb > ./pool/main/x/xorg-server/xserver-xorg-legacy_1.19.7-1+deb10u1_amd64.deb > ./db > ./db/checksums.db > ./db/version > ./db/references.db > ./db/release.caches.db > ./db/contents.cache.db > ./db/packages.db > ./conf > ./conf/distributions > ./dists > ./dists/buster > ./dists/buster/Release > ./dists/buster/main > ./dists/buster/main/source > ./dists/buster/main/source/Release > ./dists/buster/main/source/Sources.gz > ./dists/buster/main/binary-amd64 > ./dists/buster/main/binary-amd64/Packages.gz > ./dists/buster/main/binary-amd64/Release > ./dists/buster/main/binary-amd64/Packages > ./dists/buster/main/binary-i386 > ./dists/buster/main/binary-i386/Packages.gz > ./dists/buster/main/binary-i386/Release > ./dists/buster/main/binary-i386/Packages > > apt-cache policy | grep repo.local > release o=debian.repo.local,n=buster,l=debian.repo.local,c=main,b=i386 > release > o=debian.repo.local,n=buster,l=debian.repo.schlummerland.online,c=main,b=amd64 > > again to complicated ! > Advice: Describe what is actually wanted Regards Geert Stappers -- Silence is hard to parse
Re: RFC: Replacing vim-tiny with nano in essential packages
On Mon, Mar 16, 2020 at 07:40:40PM -0400, Peter Silva wrote: > On Mon, Mar 16, 2020 at 7:27 PM Guus Sliepen wrote: > > On Mon, Mar 16, 2020 at 01:02:47PM +, Wookey wrote: > > > > > I hadn't realised how fat nano is (not the only consideration of > > > course, but zile is very good on this measure and surprisingly > > > functionfull). > > > > You are comparing apples with oranges! The nano package comes with a lot > > of help files and translations. You need to compare things to nano-tiny: > > > > > Instaled sizes: > > > zile: 365K > > > busybox: 786K > > > vim-tiny: 1547K > > > nvi: 1605K > > > busybox-static: 2045K > > > nano: 2469K > > > > nano-tiny: 234K > > > so maybe we just add nano-tiny as an option to vim-tiny. > because we understand vim is not newbie friendly, but for all the old > hands, nano is not friendly to us. > 234K is a small price to pay. Not yet seen in this thread, is the package vis $ apt show vis Package: vis Version: 0.5+ts-3 Priority: optional Section: editors Maintainer: Paride Legovini Installed-Size: 1,002 kB Provides: editor Depends: libacl1 (>= 2.2.51-8), libc6 (>= 2.15), liblua5.3-0, libncursesw6 (>= 6), libselinux1 (>= 1.32), libtermkey1 (>= 0.14), libtinfo6 (>= 6), libtre5 Recommends: lua-lpeg Homepage: https://github.com/martanne/vis Tag: implemented-in::c, role::program, uitoolkit::ncurses Download-Size: 249 kB APT-Manual-Installed: yes APT-Sources: http://httpredir.debian.org/debian buster/main armhf Packages Description: Modern, legacy free, simple yet efficient vim-like editor Regards Geert Stappers -- Silence is hard to parse
Re: Debian Project Leader Elections 2020: Candidates 3 / 5
On Sun, Mar 15, 2020 at 01:08:35AM +0100, Kurt Roeckx - Debian Project Secretary wrote: > We're now into the campaigning period. We have 5 candidates this year: five > - Jonathan Carter > - Sruthi Chandran > - Brian Gupta > three That doesn't add up. Please retransmit. Regards Geert Stappers -- Silence is hard to parse
Re: enough
On Mon, Mar 09, 2020 at 08:19:52PM +, Melanie Frost wrote: > > Debian can be better than this, really > Acknowledge. Please show that you understand the meaning of enough Regards Geert Stappers -- Silence is hard to parse signature.asc Description: PGP signature
Re: enough conflict, BS
On Mon, Mar 09, 2020 at 07:09:41PM +, Melanie Frost wrote: > Dear Sam Dear All, > From an outsider perspective, this doesn't look like something that > belongs in the bug system. I don't know your point of view but it > looks spiteful. > > The volunteer was elected as a community representative and he's been > hounded ever since. It looks like he asked people to stop these games, > he resigned and he was still chased. > > Making up reasons and stories to justify this retrospectively doesn't > wash with me. Nobody ever presented any evidence of wrongdoing before, > you can't just make it up now and declare it to be true because you > are the leader. > > Please think about removing these records of vendettas from Debian. > You always talk about healing but there is no healing when these records > are persisted in all the Debian tools, you are making Debian a target > and setting the standard for future confrontation. > > Melanie That does not compute: An outsider worried about "this". In other words: The bullshit has been seen. Request: Leave this crap as manure. Regards Geert Stappers P.S. I was thinking about how to feed poison to the troll. Second thought is keeping toxic stuff out of the environment. Yes, that is way better. -- Silence is hard to parse signature.asc Description: PGP signature
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 05:33:51PM +, Ben Hutchings wrote: > On Sat, 2020-02-15 at 18:26 +0100, Geert Stappers wrote: > > On Sat, Feb 15, 2020 at 05:02:03PM +, Ben Hutchings wrote: > > > On Sat, 2020-02-15 at 14:16 +0100, Harald Dunkel wrote: > > > > Hi folks, > > > > > > > > I am maintainer for mg, currently on salsa. Problem is, upstream > > > > doesn't release tar balls anymore, but moved the code to github. > > > > No tags. > > > > > > > > How can I tell Salsa? Should I drop the upstream and pristine-tar > > > > branches on Salsa and integrate the repository on github? > > > > > > Yes. > > > > Euh ... > > > > > > Would you suggest to move the debian part to github instead? > > > > > > I think you should keep the packaging repository on Salsa, because > > > Debian contributors generally have accounts there while some do not > > > want to use (or are not allowed to use) Github. > > > > I do read that as the above 'Yes.' should be a 'No.' > > I'm interpreting "integrate" as "merge from". If it means moving to > Github, why would the *next* sentence say "move ... to github instead"? To me is packaging having a copy of upstream and its tarball releases. Hence I don't understand the 'Yes.' on "Should I drop upstream an pristine-tar" Anyway: I do hope that Original Poster has its question answered. Groeten Geert Stappers -- Leven en laten leven
f...@packages.debian.org Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 03:00:52PM +0100, Harald Dunkel wrote: > On 2/15/20 2:44 PM, Peter Silva wrote: > > fwiw, looking at the repo on github. There are tags. They're > > just dates, Ideally one would get an idea of what the tags are from > > upstream, but you could just git clone using a tag. Also github > > allows you to easily get a tarball given a tag: > > > > wget https://github.com/hboetes/mg/tarball/20180927 > > > > Thats the most recent version in Debian. > AFAIR it was created before mg moved to github. > > I will try to contact upstream. FWIW Consider to use email address m...@packages.debian.org for it. You, maintainer of package `mg` should have TWO copies of this email. One through the mailinglist. The other because I have m...@packages.debian.org CCed. As test. The idea is that it helps you to explain that you are maintainer of the package in Debian. Hope this helps. Groeten Geert Stappers -- Leven en laten leven
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 08:33:25AM -0500, Roberto C. Sánchez wrote: > On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > > Hi folks, > > > > I am maintainer for mg, currently on salsa. Problem is, upstream > > doesn't release tar balls anymore, but moved the code to github. > > No tags. > > > > How can I tell Salsa? Should I drop the upstream and pristine-tar > > branches on Salsa and integrate the repository on github? Would > > you suggest to move the debian part to github instead? > > > > Every helpful comment is highly appreciated > > Harri > > > You could probably add the GitHub project as a new remote, then through > gbp.conf (assuming you are using gbp) you can name a new branch as > 'upstream'). Alternately, you could rename the current upstream branch > as something else and then checkout the master branch from the GitHub > remote as 'upstream' in your repository. You might also have to make > some minor tweaks, but the above are the major steps. Please state some examples where that is done. Groeten Geert Stappers -- Leven en laten leven
Re: moving mg from salsa to github?
On Sat, Feb 15, 2020 at 02:16:27PM +0100, Harald Dunkel wrote: > Hi folks, > > I am maintainer for mg, currently on salsa. Problem is, upstream > doesn't release tar balls anymore, but moved the code to github. > No tags. > > How can I tell Salsa? Question seen. However I think the question doesn't an answer. Please revolt if you think otherwise. > Should I drop the upstream and pristine-tar > branches on Salsa and integrate the repository on github? No. > Would you suggest to move the debian part to github instead? No. > Every helpful comment is highly appreciated :-) The "problem" is "no more tarballs from upstream". (As in: The problem is NOT that upstream moved to some git repo server.) It is completely fine to keep all the Debian stuff at Salsa. IMHO boils the question of Original Poster down to What, or which version, should be packaged, when Upstream stopped doing releases? I see three possiblities: * Talk with Upstream about version numbering * Choose a version number scheme yourself * Ask for further advice > Harri > > https://github.com/hboetes/mg > https://salsa.debian.org/debian/mg > Groeten Geert Stappers -- Leven en laten leven
Re: News about the debhelper toolchain, challenge
On Sun, Feb 02, 2020 at 03:08:32AM +, Paul Wise wrote: > On Sat, Feb 1, 2020 at 2:39 PM Niels Thykier wrote: > > > * Support for new execute_before_X and execute_after_X targets. > > Some folks on IRC mentioned that the shorter before_X/after_X would > have been preferred by them. Feel free to challange "Some folks on IRC" to create a patch.
Re: Condorcet Internet Voting Service
On Mon, Jan 06, 2020 at 02:38:30AM +, Ben Hutchings wrote: > On Sun, 2020-01-05 at 18:01 -0800, Felix Lechner wrote: > > No one should hold a grievance for a year. The survey's author is > > welcome to send me an email with details. I would be happy to take up > > the issue with relevant parts of Debian without revealing the sender's > > identity. > > I think many of us can guess the sender's identity. > Don't give him the attention. At least be aware of a relation broken beyond repair. Regards Geert Stappers -- No one should hold a grievance for a year. signature.asc Description: PGP signature
Re: requirements and regulations concerning upgrade checks/statistics callback on program start
On Thu, Dec 26, 2019 at 11:26:26AM +0100, Tomas Pospisek wrote: > On 26.12.19 06:42, Norbert Preining wrote: > > > (please Cc) > > > > are there any requirements or restriction what a program packaged in > > Debian is allowed to do when starting up? Calibre is normally doing the > > following checks: > > - check for updates of itself > > - check for updates of plugins > > - send UID, OS, program version, and the icon theme selected in the > > program to the statistic site [1] > > > > Which of the above actions are acceptable for Debian/main? > > > > [1] https://calibre-ebook.com/dynamic/calibre-usage > > The last point seems inacceptable to me if the user hasn't explicitly > consented to it. That does bring back memory of kobo e-reader which did a "phone home" on each page of the user license agreement. I did bring back the device to the shop, got refund and spend my money on another e-reader. In other words: sending out user information is unacceptable. > Checking for updates might be annoying but is "OK" to me. Debian user did choose the Debian version, there is no need for a check on an update outside Debian. Groeten Geert Stappers -- Leven en laten leven
Re: Debian testing daily build - no kernel modules..!!!
On Sun, Nov 03, 2019 at 03:56:11AM +0100, André Verwijs wrote: > > > > Debian testing daily build has no kernel modules..!!! Reason is having booted kernel version Y and in archive available kernel modules are for version X. This does happen during development. > daily build: 10-21-2019 still good Mmm, that is more then a week ago. In that week there was another report about simular inconvinence. That was concluded with "so you just caught a bad moment" ( https://lists.debian.org/debian-boot/2019/10/msg00273.html ) I'm not aware if did work in the time inbetween the reports. (The Lonnie Cumberland report and the André Verwijs report) Please see this message as an invention for either reporting "works for me" or "next day retry also failed". > Dank U - Thank You U bedankt voor het melden - Thanking you for reporting Groeten Geert Stappers -- Leven en laten leven
Re: Opera Mail is missing on Linux
On Wed, Oct 30, 2019 at 08:56:26PM +0100, patrick.dre...@gmx.net wrote: > > Dear Woman and Man! > > Opera Mail is missing on Linux > http://ftp.opera.com/ftp/pub/opera/mail/1.0/. > How is the problem solved? https://wiki.debian.org/Opera > With kind greetings! Yeah. And if we where in the same pub I would invite you to follow me outside. Groeten Geert Stappers -- Leven en laten leven
Re: Git Packaging Round 2: When to Salsa mirror
On Sun, Sep 08, 2019 at 10:05:17PM -0700, Russ Allbery wrote: > Sean Whitton writes: > > On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote: > > >> You are encouraged to mirror your repository to Salsa so that people can > >> find more of the Debian packaging in one place. > > > Hmm, if the Vcs-* are set correctly, what's the value of mirroring to > > salsa? (I don't object in the least; just wondering about the value.) > > Higher chance that the repository won't go away. Where is Alioth? As retoric question. What about Vcs-Mirror-* for actual telling where a mirror is. In case of `git` is "mirror" a "clone" Groeten Geert Stappers -- Leven en laten leven signature.asc Description: PGP signature
Re: GPL
On Sat, Aug 17, 2019 at 12:14:12AM -0300, Anderson Ribeiro [ MAD ] wrote: > Good evening to all. > Guys, I'm studying packaging. > Because I am learning. > > I am trying to package it (Pulseaudio-version-12.99.2). > In the COPYRIGTH > version is as follows. > > Copyrigth 2018-2019 Pali Rohár > > > PulseAudio is free software; you can redistribute > it and / or modify > under the terms of the GNU Minor General Public > License as > published by the Free Software Foundation; version 2.1 of > License, or (at your discretion) any later version. > > [ your choice - I can > put the version I want myself. Type: or version 2.1 of License 3 ] ? > My advice: Stay close to original. In this case: 2.1 Groeten Geert Stappers -- Leven en laten leven
Re: regarding non-free firmware for wi-fi and ethernet
On Thu, Jul 25, 2019 at 08:00:24PM +0300, Abibula Aygun wrote: > Hello Debian Team, > > I represent the AcademiX GNU/Linux project team. > I am one of the developers. > We use some Debian Buster to make this distribution customized for our > needs on education. > Also we use the Debian Installer because is fery easy to use. > We have an little problem. > The installer can't detect many simple wi-fi or ethernet hardware. Things > that was ok on Stretch version. > There is any way to insert the non-free firmware on our distribution? > I've seen that you have an unofficial iso of Debian Buster filled with > non-free firmwares. > What can we do to insert the Firmwares on our distribution ? > You have an unofficial Debian with all non-free firmwares. As far as i know > is ok to include in AcademiX distro the > non-free firmwares for wi-fi and ethernet without alterate the licence of > the manufacturer or the code of the firmware. > > Right? > > It is ok to insert in Academix GNU/Linux installation media the non free > firmwares? > Anyway, the non-free firmwares are used by the installer an not by final > installed system. Please visit https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ to see how Debian tackled/nailed/circumvent it. > We want to insert it but waiting advice from you. > > Kind regards! > We dont want to make some non legal problems. > I know that the firmware used on unofficial iso are redistributable. Can we > use it on our ISO? > > Thank you in advance, > > Kind regards, > > Aygun Abibula > > Developer and PR at AcademiX GNU/Linux > > https://academixproject.com Most likely you will appriceate https://www.debian.org/blends/ Groeten Geert Stappers -- Leven en laten leven
sbuild: do not fail when there are alternatives
Package: sbuild Previous-Subject: Re: seccomp woes Original-To: debian-devel@lists.debian.org On Fri, Jul 19, 2019 at 11:28:36PM -0300, gregor herrmann wrote: > On Sat, 20 Jul 2019 00:21:10 +0200, Christoph Biedl wrote: > > > * Centralize the list of supported archs in the seccomp packages. By > > either creating an empty libseccomp-dev for the archs where seccomp > > is not supported, or by creating a "libseccomp-dev-dummy" for these. > > In the latter case package maintainers would have to do a one-time > > change of the build dependency into "libseccomp-dev | > > libseccomp-dev-dummy" and can focus on other issues then. > > AFAIK this won't work because sbuild on the buildds is configured to > only use the first alternative from a list of build dependencies. Reported as bug. Not checked if it already was reported before. Not checked if it really fails when it can't find the first alternative from list of build dependencies. Thing is that sbuild _might_ be blocking a nice way to cope with libraries that are not available on all architectures. Context at https://lists.debian.org/debian-devel/2019/07/msg00405.html Groeten Geert Stappers -- Leven en laten leven signature.asc Description: PGP signature
Re: hping3: git repository missing
On Mon, Jul 15, 2019 at 03:28:48PM +, Stefan Pietsch wrote: > Dear Debian developers, > > the git repository for hping3 does not exist. > > apt source points to git://anonscm.debian.org/collab-maint/hping3.git > > > $ git clone git://anonscm.debian.org/collab-maint/hping3.git > Cloning into 'hping3'... > fatal: unable to connect to anonscm.debian.org: > anonscm.debian.org[0: 194.177.211.202]: errno=Connection refused > anonscm.debian.org[1: 2001:648:2ffc:deb::211:202]: errno=Connection refused > Yes, that is what https://tracker.debian.org/pkg/hping3 also says. At https://anonscm.debian.org/ is a link to https://alioth-archive.debian.org/ However under https://alioth-archive.debian.org/git/ is indeed no hping3 So `apt-get source hping3` might a good starting point to revive "hping3" Groeten Geert Stappers -- Leven en laten leven signature.asc Description: PGP signature
Re: Getting rid of codenames (Was: getting rid of "testing")
On Fri, Jun 28, 2019 at 08:51:18AM +0800, Yao Wei (?) wrote: > How about getting rid of codenames altogether? Like we use unstable > for unstable, experimental for experimental as it already is, no > testing and buster but debian11, debian12, etc. > > Although it is eliminating some funs but it is much more predictable > and simple to remember. I also confused squeeze with stretch. > By using symlinks at the apt repositories we can have both. debian10 symlinks to buster debian11 symlinks to bulleye bookworm symlinks to debian12 On Tue, Jun 25, 2019 at 09:38:57AM +0100, Simon McVittie wrote: > On Tue, 25 Jun 2019 at 13:11:09 +0500, Andrey Rahmatullin wrote: > > > > I guess only (most?) Debian contributors and hardcore Debian users > > remember the order of the codenames and their mappings to current > > stable/oldstable/testing and to numeric versions. > > Yes, exactly. This is a frequent request from those of my colleagues > who mostly use other distributions, but occasionally have to interact > with Debian, and can't remember whether stretch is older or newer than > jessie. This is going to be particularly bad after the buster release, > when buster and bullseye are current, and even worse after the bullseye > release, when buster, bullseye and bookworm will all be relevant. > > Ubuntu is easier in some ways (because the alphabetical codenames go in > a logical sequence) but harder in others (because the distinction between > LTS and non-LTS isn't obvious from the codenames). > > Back when the release team decided on a per-release basis whether this > was a "major" or "minor" release, we had the excuse that we had to use > a codename for testing because we didn't know whether etch would be > released as Debian 3.2 or Debian 4.0; but now that we've decided that > every release is a major version, we can predict well in advance that > Debian 10 will be followed by Debian 11 and Debian 12, so there doesn't > seem a whole lot of point in obfuscating it. So true > With more emphasis on the version numbers, my non-Debian colleagues would > still have to learn (or look up) which release is the current stable, > but given that information they would immediately also know which release > was the previous one (subtract 1) and which release is under development > (add 1). > > Referring to testing in speech/writing as something like Debian 10 > alphas/betas/pre-releases (to express that it *will be* Debian 10, but > it isn't really Debian 10 *yet*) might make more sense to non-Debian > people, and might have the desirable side-effect of having more Debian > contributors get the message that it's a means to an end (making > the next release happen) rather than a product in its own right. In > machine-readable contexts like sources.list it's probably best to use > something like debian10 (or deb10, as in stable updates' version strings, > or just 10) so that it doesn't have to change on release day. > > smcv > Groeten Geert Stappers P.S. rolling symlinks to testing tumbleweed symlinks to testing -- Leven en laten leven
Re: Is screenshots.debian.net at risk?
On Sat, Mar 23, 2019 at 12:13:37PM +0100, Christoph Haas wrote: > Fellow devs, > > bear with me if the topic of the upcoming european copyright law (aka > §13) has been discussed in other mailing lists. As being responsible for > screenshots.debian.net I honestly am a bit worried about the > implications. As usual??? IANAL. > > Management summary: screenshots.debian.net is a web site that I > developed many many years ago and which is since then providing > user-generated screenshots for applications we manage in Debian. > Everyone can upload screenshots which are then moderated by pabs and me > before being published. We try to take care that screenshots of non-free > packages are not published to avoid copyright issues. And we claim to > publish screenshots under the same license as the software itself is > published. This has been the consensus after discussions on this list > ~10 years ago. Screenshots can be browsed and searched at > https://screenshots.debian.net/ and are also directly linked to from a > lot of web sites like packages.debian.net or packages.ubuntu.com. The > site currently provides 8500 screenshots, has a pretty good uptime and > according to the web server stats gets a good amount of requests. > > I am not only bringing this topic up because there will be a large > amount of rallies today (at least in Germany) and the topic is very hot. > The main reason is that I am working on an updated version of the web > site that will have a revised moderation workflow. pabs suggested that > we should allow all DDs to freely upload screenshots. That is already > implemented in the upcoming version and will be handled by our valued > sso.debian.net client certificates. That of course would mean that DDs > have to take care of copyright problems when uploading stuff. > > A further idea of me is to allow everyone to use SSO providers like > Launchpad, Stackexchange, Google, Amazon and Github. I was considering a > system where users would have to upload a certain number of "good > screenshots" before being allowed to upload freely. I hoped to attract > more people to upload screenshots without the hassle and delay of going > through moderation. pabs and I discussed whether it's worth doing that. > Will there really be so much more user content that it's worth allowing > that? > > Most of us are not lawyers so it may be hard to dig out the ultimate > truth. But I am personally worried because the server is run under my > name and I would not like to get into personal trouble while running a > platform that is providing user-generated content. Because that's what > all the EU law fuss is currently about. > > I would welcome your thoughts on that. Thanks. I'm in a simular situation. I do provide servers with wikis to local user groups. Every person smart enough to register an account upload whatever they please. Do I go implement "filters"?No. Do I go shutdown the various wikis?No. Do I think that "EU article 13" will harm the libre Internet? Yes Groeten Geert Stappers -- Leven en laten leven signature.asc Description: PGP signature
Re: Debian vs Linux namespaces, NMU lsb-base
On Sat, Mar 23, 2019 at 09:49:09PM +0800, Shengjing Zhu wrote: > On Sat, Mar 23, 2019 at 8:41 PM Harald Dunkel wrote: > > > > Hi folks, > > > > AFAICS there are several packages that appear to be unaware of / > > do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng, > > probably everything using pidof or pidofproc from /lib/lsb/init-\ > > functions). > > > > I noticed that containerization and Linux namespaces are not number > > one priority for Debian, but do you think this could be addressed > > for Buster? Its pretty annoying if you try to maintain the Debian host > > system, and a LXC container is affected instead. > > > > > > Thanx in advance > > > > Harri > > > > https://bugs.debian.org/888569 sysv startup script stumbles over smtpd running in a LXC container > > https://bugs.debian.org/888743 pidofproc returns PIDs in foreign chroots and containers > > https://bugs.debian.org/858837 lsb-base: pidofproc should limit itself to processes in host system if running on an LXC host > > https://bugs.debian.org/924551 startup script affects bind running inside a container > If I read these bugs correctly, all are the same thing and it's the bug in > lsb. > And the straightforward fix mentioned in #888743 and #858837 is to use > `pidof -c` instead of `pidof` in pidofproc function provided by > lsb-base package. > > I think there's no harm for this patch. Quoting manual page `pidof` | -c Only return process PIDs that are running with the same | root directory. This option is ignored for non-root | users, as they will be unable to check the current | root directory of processes they do not own. What would be the harm to the Buster release if lsb-base got NMU with https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=init-functions.diff;msg=37 ? Groeten Geert Stappers -- Leven en laten leven
Re: Debian vs Linux namespaces
On Sat, Mar 23, 2019 at 02:26:08PM +0100, Ond??ej Surý wrote: > > On 23 Mar 2019, at 13:34, Harald Dunkel wrote: > > > > Hi folks, > > > > AFAICS there are several packages that appear to be unaware of / > > do not care about containers, e.g. opensmtpd, bind9, apt-cacher-ng, > > probably everything using pidof or pidofproc from /lib/lsb/init-\ > > functions). > > > > I noticed that containerization and Linux namespaces are not number > > one priority for Debian, but do you think this could be addressed > > for Buster? Its pretty annoying if you try to maintain the Debian host > > system, and a LXC container is affected instead. > > > Hi Harald, Hello mailinglist, > since you are using non-default init system, I would recommend sending > patches along with your bug reports if you want to get niche things fixed. As far as I can see is Harald exploring the amount of niches and a generic solution. > Ondrej > > > > Thanx in advance > > > > Harri > > > > https://bugs.debian.org/888569 > > https://bugs.debian.org/888743 > > https://bugs.debian.org/858837 > > https://bugs.debian.org/924551 > > > Groeten Geert Stappers -- Leven en laten leven
Accepted radvd 1:2.17-2 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 20 Jan 2019 21:23:08 +0100 Source: radvd Binary: radvd radvdump Architecture: source amd64 Version: 1:2.17-2 Distribution: unstable Urgency: medium Maintainer: Geert Stappers Changed-By: Geert Stappers Description: radvd - Router Advertisement Daemon radvdump - dumps Router Advertisements Changes: radvd (1:2.17-2) unstable; urgency=medium . [ Ondřej Nový ] * d/changelog: Remove trailing whitespaces * d/control: Remove XS-Testsuite field, not needed anymore . [ Luca Boccassi ] * No router advertisement on tunnel interfaces patch . [ Geert Stappers ] * Added .gitignore files. * gbp Debian branch is debian/master * Removed unused debian/patches * DEB_BUILD_OPTIONS prevents check, opened: #919926 * Removed builder config from d/gbp.conf * Upload Checksums-Sha1: e0e14defc4637a101d31122e911de2db9716e410 1906 radvd_2.17-2.dsc eb2889ef738be41c7b82691e1ce2fe2d771f263c 14084 radvd_2.17-2.debian.tar.xz df761a61d6087e163ca7f4b504bcf4691efcfe29 114808 radvd-dbgsym_2.17-2_amd64.deb 5399026199ef272084f77a423753b58c3b2f3a3a 6375 radvd_2.17-2_amd64.buildinfo 35b2770ef5c6ed5f246c26c5f3d5349a5f583988 75776 radvd_2.17-2_amd64.deb 948614264ec61fc61f4b9587c4d27b692033eb92 30448 radvdump-dbgsym_2.17-2_amd64.deb 2ee9821e46a88af8b1a7aa92408096f2ef186091 30404 radvdump_2.17-2_amd64.deb Checksums-Sha256: 4ce30f553d8d9510c41aafac29b52012600fd2c9a4cb78bea903531ecd30d2de 1906 radvd_2.17-2.dsc e6694221c768e8b7d76b9879ce549f4d71425f495b1020106dadd936274fab3f 14084 radvd_2.17-2.debian.tar.xz d5e3ff4de0383933fa2e1eca0def4acb453420d55128e43fb551e9d7fabc67c0 114808 radvd-dbgsym_2.17-2_amd64.deb 287e357d0f2ade8b89a2f6b7774496cb6ce0ff2b72dc3aa7938773628cb0df31 6375 radvd_2.17-2_amd64.buildinfo 0d64a1c2f6735ba37fffb6a532d204d235ba6b9441953acc6cabe9383b3af5ac 75776 radvd_2.17-2_amd64.deb 97562c3e3247d38665762474d302b6b10e4bd8a25e571c1ab88625c25d63e6ea 30448 radvdump-dbgsym_2.17-2_amd64.deb 1edee98902c9c236ec1650a051f9a212827e442d5e45d8da6ee96d2f8dde1821 30404 radvdump_2.17-2_amd64.deb Files: 09d09ed3691be322129eb968414eda01 1906 net optional radvd_2.17-2.dsc c02c35f5b68064b1587e3a861426f261 14084 net optional radvd_2.17-2.debian.tar.xz a5c743997f5a5f618a2dd983486daaee 114808 debug optional radvd-dbgsym_2.17-2_amd64.deb 864f35f36379fc2ca0d561b4914b8c0d 6375 net optional radvd_2.17-2_amd64.buildinfo 9b40fac6758020e4418687efec49e732 75776 net optional radvd_2.17-2_amd64.deb a8744d52aef7577f1576948d4331 30448 debug optional radvdump-dbgsym_2.17-2_amd64.deb aad0c1ca84ddacd3cc9363d62a023eef 30404 net optional radvdump_2.17-2_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEin8gjG2ecykWV0FNITXRI9jBm+wFAlxE4Q8ACgkQITXRI9jB m+ztAw//aJyIQt54TAMDfczCxo8N7PKZG3OFaNzIE9Xij/xJslwjlYpiqWRS4qwB 56QJeOXXaXrRm7pgPrvzhfLZZCoQD/rTpSE2C2HgBwXI/4QBMyqYJDMfaZCqNR3G 2IXQTznktC1wqyEJZeSfJxvdW920riN27FHHrIO1jJ1lDLGcxPZuDy8Jlye0pWlF CCzKPNUgBoQXW/PeWrihX7E/9/CAbPCrBg5cmorLS3mwAdTqJNcxXTcEHh2TiBq4 THvyEaEpBMWQrXurvgLm4pfKbLyAeAgJJVPm5AT6MCGlVkfczCOkEO5FT2ux6IGv 1bQdGA+bPCRo5IAfDm1sZxWi2iFQt/PZvCDWrhtloIm5aVd3OmYb6dtlCeBWQQ75 OFytSUybSw+O9KDUI+ZGzFPhzbIgCCVr/i76ervEco0aGC1wCgS7CtfKGXmKafho 7QRLzYFUjEARNMqc8aGgist7bKW1wpyDB020Y8cpMNl6bvzlG0oHKMV2dtWzhtuN X2vev6fgTy8zQrke3gQuAwPcNEjBZIWsH0uNy4/Hhc8AW+qWss6/gpkr1+2ZE+qv PK4ZrF/RQySFLZGwkK/xl6CyaxBx9bCOS8eb/ttqHI+OYkzrpt6AKeU3WGxuXaHu 3U3KKslf5uYa4DcoxbPrZ9+IbKAxY2S3662+J2kxY4kREMc2W/w= =dywf -END PGP SIGNATURE-
Accepted pelican 4.0.1+dfsg-1 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 13 Jan 2019 18:46:23 +0100 Source: pelican Binary: pelican pelican-doc python-pelican Architecture: source all Version: 4.0.1+dfsg-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Applications Team Changed-By: Geert Stappers Description: pelican- blog aware, static website generator pelican-doc - blog aware, static website generator (documentation) python-pelican - transitional dummy package Closes: 875255 913875 918447 Changes: pelican (4.0.1+dfsg-1) unstable; urgency=medium . * New upstream release. (Closes: #913875) * Python3. (Closes: #875255) * That fixed a FTBFS (Closes: #918447) * Added 'pristine-tar = True', related to #918360 * Removed a debian patch, upstream file not more present * Added myself to Uploaders. Checksums-Sha1: 8f8e341148374b2b7f908357f5eab00fae4248b1 2391 pelican_4.0.1+dfsg-1.dsc eca937f1a038884d4677917acbff6fb17bb5c62d 479500 pelican_4.0.1+dfsg.orig.tar.xz 07bbd60c3ce5371fc98eb93c11b3a78873f8e732 17268 pelican_4.0.1+dfsg-1.debian.tar.xz 56db416b92fc0997b063baea78ae2a2f1cddd182 185024 pelican-doc_4.0.1+dfsg-1_all.deb be2734826018a7856298f5bd9d75e95c6687fb8e 94368 pelican_4.0.1+dfsg-1_all.deb 03b27831db13f8be109fa8431ead4e833b25a155 7590 pelican_4.0.1+dfsg-1_amd64.buildinfo 3b33a4996711d12dffc930823484e7fa4d51e7bc 20416 python-pelican_4.0.1+dfsg-1_all.deb Checksums-Sha256: d98f9f23d34b93246acadd52f6ca11ef1cc694fc5d3949b31a1d84e9e1a67c8c 2391 pelican_4.0.1+dfsg-1.dsc 8570e63e4b2e49ee7496d823ee0c5f17165ed20fa43c88f878f5beb66bfcbacb 479500 pelican_4.0.1+dfsg.orig.tar.xz 6e9c3de3f3cd778082d0b2ec37ada689e9612a59c417d97af5b6b18945dbfab2 17268 pelican_4.0.1+dfsg-1.debian.tar.xz b55774944b647e27b82a34638544e50d1d0cd2e201cb88c0bd741edd6fac44c1 185024 pelican-doc_4.0.1+dfsg-1_all.deb c2b975846f4d52139a841fabfc6463b107bf5bdc5b9355a4920bec512f71fc3c 94368 pelican_4.0.1+dfsg-1_all.deb 5550094a55c337ca0f6eb32105fc7dc7044019dbcb363cda670adda26c621d9a 7590 pelican_4.0.1+dfsg-1_amd64.buildinfo b1da8eb7e027e4e973defdf4b6945433d5976f4f92616d0ea513789ab11440f9 20416 python-pelican_4.0.1+dfsg-1_all.deb Files: 00d54211773bed94388b2492ab5025cd 2391 web optional pelican_4.0.1+dfsg-1.dsc 03e6c42b3e1c52ed284eab6f116251f1 479500 web optional pelican_4.0.1+dfsg.orig.tar.xz 1c7ad5dd5a972ea2756719fdbd0a0373 17268 web optional pelican_4.0.1+dfsg-1.debian.tar.xz 0d8999e86c795d25e3c7a5b403c681eb 185024 doc optional pelican-doc_4.0.1+dfsg-1_all.deb 4b49ef1fc04d15eef730db081a95072f 94368 web optional pelican_4.0.1+dfsg-1_all.deb 00f27db469976b6768701f39b226380c 7590 web optional pelican_4.0.1+dfsg-1_amd64.buildinfo 600567af2185012a40cf98973da72a6e 20416 oldlibs optional python-pelican_4.0.1+dfsg-1_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEin8gjG2ecykWV0FNITXRI9jBm+wFAlw7fSEACgkQITXRI9jB m+zNWA/8DKsLrVovdPM4XF3LwbojyEXV+jRRg/fdsiqsIvzw77irArj8AN9Pt/sE QpPG88p73kKE7FLxw55K3p4T4tklTn7kJuFFqkNd6d3zyXwFL9ryWGIXD14dicpU 4SaSCPgfOTKIkbMwdR0hfA9lXVxRTT39dqMmvY2/+QEyIgBX/dDmRvtiTCPjg3dq cCEBoQdc+Xuo+lQfttXPr93/f5yPB5Iftj36hXzZhIlxSOKFPNN8Qp4NIqvPZhy0 jfS59ql/bd7gkzgW+paTncHu9HoBTuuX0EZ68o34FNU3nItaXZQ2ls53PTzRoFMZ j93DgmGks45X1VXOrPSqiQhA5IevXjgKxQq8lZwnaLickSDr0XtFTIkrjkdb5dIp rQ8LU+eYl1se5iISjI4WntNOM6h2sxx6r8RNqkX0BNCjBts2msrVl6uCrluHXEou MCPe1xGRif8vrlu0H8sps1Uib7eRw32CnlIlRXB0ynvTpNMxRaqF6meSy/mIUKjn QN8xlwb8iEmml6vlg6Tp7D/9ICdMyHXbxGWDCSzHrqT/RK1GOpOdQvVB8PwBpISS oMt8YBBaxg61Utf0Yt80Zhh2FpYzcCxn4Q/VBE2psDVDAnoB28ed88wOngIhmaCo +Wa8mU2rHJs9kumHI6znZ3zunBRhpRnh8FTEvGziX7x8JmtmvXU= =UV+X -END PGP SIGNATURE-
Accepted fiche 0.9.1-1 (source amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 12 Jan 2019 15:35:42 +0100 Source: fiche Binary: fiche Architecture: source amd64 Version: 0.9.1-1 Distribution: unstable Urgency: medium Maintainer: Geert Stappers Changed-By: Geert Stappers Description: fiche - Receiver for command line output pastebin Closes: 848338 Changes: fiche (0.9.1-1) unstable; urgency=medium . * Initial release (Closes: #848338) Checksums-Sha1: a218159ceb2be1876d5b3ad0ab960dbe29166d94 1777 fiche_0.9.1-1.dsc 8809cbb12d3385e2859a482196885c02892d9c29 10246 fiche_0.9.1.orig.tar.gz e47378997aedee1b5c59672acd12957a93ec403a 4472 fiche_0.9.1-1.debian.tar.xz 103f33ecc2d17664f7379aa272d879de7133b789 8592 fiche-dbgsym_0.9.1-1_amd64.deb 4075213553d738a3ee504370c38073b5f1d0c259 5441 fiche_0.9.1-1_amd64.buildinfo a308cf374940d700399758df56a7c03765a96ae8 9140 fiche_0.9.1-1_amd64.deb Checksums-Sha256: 9803d184ada755763f3808e2c222ff48d8168d07acb9d70b6233fc6bf16cc207 1777 fiche_0.9.1-1.dsc f0cb279a2c2a4c0d1debcf56785fd8731a1427d2524221678cf69c9aaa85e831 10246 fiche_0.9.1.orig.tar.gz 5b3b591ff53ea1734dee7e97c19b12e7964f87e73e9a1baab1e74714affbbb76 4472 fiche_0.9.1-1.debian.tar.xz 71913bec049a220e2d2a913ff603bc48abf107ae64f80ff716b7fe02e5200159 8592 fiche-dbgsym_0.9.1-1_amd64.deb 0be998e13642ecae3a90f04953573ea0427ebd3196229589d36ccd0fd8646d56 5441 fiche_0.9.1-1_amd64.buildinfo 2a325f837459b29253b32e0b5ce09528b4e2ca014787e200a06a5a6308e3a786 9140 fiche_0.9.1-1_amd64.deb Files: f62d8adbd746fbda0c5dc964ad95cb62 1777 net optional fiche_0.9.1-1.dsc 3e3d5ba0b31e0182ed14f4bc50f38ae3 10246 net optional fiche_0.9.1.orig.tar.gz b9df6fef1a6e789e01d174e907d68448 4472 net optional fiche_0.9.1-1.debian.tar.xz 0de88a5578919037ceba65e7db819b6f 8592 debug optional fiche-dbgsym_0.9.1-1_amd64.deb 4227db9009de7844489d5df75df5e424 5441 net optional fiche_0.9.1-1_amd64.buildinfo d7597127a4f40fab8130895a4b2f4b74 9140 net optional fiche_0.9.1-1_amd64.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEin8gjG2ecykWV0FNITXRI9jBm+wFAlw6AogACgkQITXRI9jB m+yZqxAAtXQM52eXDOzTcG48McQusiGnLDvKdHHscfTufAayP2TZ5DeFYo87t6Bl WXC1CzjXEByoI5kogdKF/RPqT+76fN5mnrXKt/pbi+6pdooEoSFN4M9Zcu2oTh9g onx/vPUOr7g/kWt+FTIUsK2JDeSSozlY6nEO4fyGmyvuNW2GAvIYh06mOOLcdCA4 PD/UACg6Yrr/+pkvK+BHemyRnupX5iO3eEe3VBqXRR0lV5Q0LNLbYQvjDOa8UQUT 2UlNd/+l5IURIxoZLzW2rcX5af3LXVLTG4gOTJwfqsBge6AeTjNxDY9qqweM+Xk/ tYz5J/PgYmNEHlGfBeiWPfhgNpCyltZ8lBkRI8dfpsEnw18FUzY0wGH/Gt+aSCfD F3DG2/grO0qpuc9WuS0MZcD3PEJiNNgtFct89xh0LU7pM/TC5UG4UowA02HBOQy6 l2+wirjaXy02rf7w5zFoL+igxLiVF8deRKqT7tb/ZTLiqhYd5kQg79hSYuVxQ3xd JIcwNQbZD01SeV5TXdN2q86wdcYj+ALPwLeVktofMCoSLzIfKb60hRChFqBUe2jP 3btsD9jmNxY3XtwR/MQNaLMvV74sqd25OejsgiKjC9draQHAR/vubuRPwYk2sCuA +fnGpA4sGpmtc2eAw5zuvPxsIB9w1/ULYE7+96ybhweBtJ820Tk= =gf5x -END PGP SIGNATURE-
Accepted pelican 3.7.1+dfsg-2 (source all) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 05 Jan 2019 15:27:25 +0100 Source: pelican Binary: pelican pelican-doc python-pelican Architecture: source all Version: 3.7.1+dfsg-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Applications Team Changed-By: Geert Stappers Description: pelican- blog aware, static website generator pelican-doc - blog aware, static website generator (documentation) python-pelican - transitional dummy package Closes: 917468 Changes: pelican (3.7.1+dfsg-2) unstable; urgency=medium . [ Ondřej Nový ] * d/copyright: Use https protocol in Format field * d/control: Remove ancient X-Python-Version field . [ Geert Stappers ] * d/control has Salsa in VCS fields. (Closes: #917468) * Build depend on python3-feedgenerator Checksums-Sha1: 0832a6536577676b39ef01ea6994c4118cf1ba06 2344 pelican_3.7.1+dfsg-2.dsc cba254e9d73bec821104afa095b41b9c0a833798 17156 pelican_3.7.1+dfsg-2.debian.tar.xz 5c9d3d208e5ac85be43f01526eb6fa87fd59ba7f 187780 pelican-doc_3.7.1+dfsg-2_all.deb c6b265161e80140a3fab8c0b269c5688767dfbd0 85964 pelican_3.7.1+dfsg-2_all.deb ac774e0aa3ffd82e2066b99bc4b9adc37b8bb3b8 8366 pelican_3.7.1+dfsg-2_amd64.buildinfo 52160e5795b935de8b340b3a224dfc4845bb4959 19300 python-pelican_3.7.1+dfsg-2_all.deb Checksums-Sha256: 64900822f89eb17473b68f88dc8e1c12e519a59757312e9a56e6cafe4d9806cc 2344 pelican_3.7.1+dfsg-2.dsc 61294f9d37f91833dc556c7620b89506d41a5b7ef3d504e6ce93c50f10bfbabe 17156 pelican_3.7.1+dfsg-2.debian.tar.xz ee14a21fe7345807606e7a64a8593bf180716821a8e2d8fec5e4414c9c353994 187780 pelican-doc_3.7.1+dfsg-2_all.deb 35609a9274ea9f77e22ec2e48efcf91141f67fc0df3d537e9b955f67cac2b2a3 85964 pelican_3.7.1+dfsg-2_all.deb 104297dad56da3f5a6303c4b8644ea743a5ff1ee5254009bd6fd9e936f644a92 8366 pelican_3.7.1+dfsg-2_amd64.buildinfo 161b3494c0752498d2b252da8fab279ade80d8fda983dd0100ee55b5364497bb 19300 python-pelican_3.7.1+dfsg-2_all.deb Files: 37af8edcf36ae3eec0a688c85166a1bf 2344 web optional pelican_3.7.1+dfsg-2.dsc 42723b8654dda3652641435b389e74be 17156 web optional pelican_3.7.1+dfsg-2.debian.tar.xz b2d82cd34ee5545fdc5f204c2c1043c2 187780 doc optional pelican-doc_3.7.1+dfsg-2_all.deb ad71aaf6e91c9bfeaae0bc6a4611e3d0 85964 web optional pelican_3.7.1+dfsg-2_all.deb 032dbbf117ae909555488637844b1374 8366 web optional pelican_3.7.1+dfsg-2_amd64.buildinfo 60d0740a78e1ee21bde96cb5fd2ce6b7 19300 oldlibs optional python-pelican_3.7.1+dfsg-2_all.deb -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEin8gjG2ecykWV0FNITXRI9jBm+wFAlww2OsACgkQITXRI9jB m+xodhAAoS2YB3HG+0de2FFSlGPQElRGplOt5nEzL0Mh6Rx7tLA1WceAb2iKKDIU r0TGJ7gljfSWwp/d9guTydMOk9Zoie41uoMQ7XMd7kGn/Qyjq03Tao8/ThSLxY6a FrI50eXNXhxGOD2eTgIeyWNKvuyJBqKLTurzoO0wUaFTIJpN4fdisduMoH/blPhI /DvCjwRNB7q/Jjk2o44Dc+goAllKfo1l9n5gZg38B2tPeMbqn0NnUiLlnlB3YksM ybkb413WNbjtBdLZzvDq0IQEtBnyVx8/dZIks9tipNFWbBgV4izTBPVniZS8xJmI OZVWXIE6B+5pxE0vhiXznUut5HKmhYItcZqFV/z83mxXAsNmId8bPwNZ6jFYaEvG Utw019MpESO5RVKd78o9Zs4ftepZpcRFvhKXS+OX7MxPj5SiAvUU+qN05f/UGX1O kor9ctpbv7UWGOlG7FOUJSJFzlz1rd7/BODlsV3Qyvvtv1uEHYcd0+nfoNlwdp/n ogyOTzu0V5gz05IUqshxict112gTEBkdoGdQlRfyeoBCqqToMnv0kHoUgPztCx/f joGQZSrz8SgkVoMElHsi58lDfHbBrRF9PEnP678ja9Jmi0itwmrbpkHz1QJu/W9X uMMVO4T4WZYb2xhmQavoyJD49u0tCtDx4BV2idJ5p9sPfekzQZw= =+6r7 -END PGP SIGNATURE-
Re: Questions about VRF function in /etc/network/interfaces
On Sat, Dec 29, 2018 at 01:36:37PM +0800, Simon Jones wrote: > Hi all, > > I'm working on SONiC project management vrf function SONiC: https://azure.github.io/SONiC/ Software for Open Networking in the Cloud, SONiC VRF: https://en.wikipedia.org/wiki/Virtual_routing_and_forwarding > under debian with kernel 4.3. > > This is my OS: > > > # uname -a > > Linux dut211 4.9.0-7-amd64 #1 SMP Debian 4.9.110-3+deb9u2 (2015-12-19) > > x86_64 GNU/Linux Euh, that 4.9 is not 4.3 ... > This is SONiC project management vrf function: > > > https://www.youtube.com/watch?v=uAHmZKEdqDE=youtu.be > > > Now I have to rewrite /etc/network/interfaces to implement this function, > but I got errors, so I want to know if there is demo about how to define > VRF interface and implement VRF function in /etc/network/interfaces. > > As I follow your man file, I don't know how to do, and gots errors. > > This is my try on this feature, rewrite /etc/network/interfaces like this > > iface eth0 inet static > > address 172.18.8.211 > > netmask 255.255.255.0 > > ## management network policy routing rules > > # management port up rules > > up ip -4 link add mgmtvrf type vrf table 10 > > up ip -4 link set dev mgmtvrf up > > up ip -4 link set dev eth0 master mgmtvrf > > up ip -4 route add default via 172.18.8.1 dev eth0 table 10 > > up ip -4 route add 172.18.8.0/24 dev eth0 table 10 > > up ip -4 rule add from 172.18.8.211/32 table 10 > > post-up sysctl -w net.ipv4.tcp_l3mdev_accept=1 > > # management port down rules > > down ip -4 route delete default via 172.18.8.1 dev eth0 table 10 > > down ip -4 route delete 172.18.8.0/24 dev eth0 table 10 > > down ip -4 rule delete from 172.18.8.211/32 table 10 > > down ip -4 link set dev eth0 nomaster > > > This is errors I got > > > Dec 29 02:38:48 dut211 ifup[8690]: RTNETLINK answers: File exists That means "defining something twice is not allowed". See if you can find what is being defined for a second time. > > Dec 29 02:38:48 dut211 ifup[8690]: ifup: failed to bring up eth0 > > Dec 29 02:38:48 dut211 systemd[1]: networking.service: Main process exited, > > code=exited, status=1/FAILURE > > Dec 29 02:38:48 dut211 systemd[1]: Failed to start Raise network interfaces. > > -- Subject: Unit networking.service has failed > > -- Defined-By: systemd > > -- Support: https://www.debian.org/support > > -- > > -- Unit networking.service has failed. > > -- > > -- The result is failed. > > Dec 29 02:38:48 dut211 systemd[1]: networking.service: Unit entered failed > > state. > > Dec 29 02:38:48 dut211 systemd[1]: networking.service: Failed with result > > 'exit-code???. > > > Thank you. > Groeten Geert Stappers -- Leven en laten leven
Re: Uncoordinated upload of
> > Instead of putting all the blame on > > Why would I need to communicate that? Because coordination needs involvement from all
Pretty Easy Privacy
Hi, There is PEP, https://en.wikipedia.org/wiki/Pretty_Easy_privacy project website is https://www.pep.security/ However `apt search pep` doesn't show it? Neither is a WNPP bugreport at hand. Is Pretty Easy Privacy available in Debian? Groeten Geert Stappers -- Leven en laten leven
Debian 25 on thursday 2018-08-16
Hi, Thursday 16th of augustus becomes Debian 25 years. Let's celebrate it Cheers Geert Stappers
Re: A message from CMake upstream: announcing dh-cmake
On Sat, Jul 07, 2018 at 12:25:15AM +0200, Mattia Rizzolo wrote: > On Fri, Jul 06, 2018 at 04:40:44PM -0400, Kyle Edwards wrote: > > On Fri, 2018-07-06 at 21:00 +0100, Colin Watson wrote: > > > If the libraries in question are DFSG-free themselves, there's no > > > DFSG issue and you don't need to remove them from the tarball (and > > > we'd generally encourage not modifying the upstream tarball > > > unnecessarily for upload to Debian). The policy about bundling is > > > separate from the DFSG. Of course it'd be incumbent on whoever's > > > doing the Debian upload to actually check the licensing status. > > > > Thank you Colin, this is good to know. In that case, I will investigate > > VTK's DFSG issues when I get a chance. If there's something in there > > with a licensing issue, then we as upstream would like to fix it. > > Whilst everything Colin wrote is true, there is also the detail that we > do a copyright and license check for every file shipped in the tarball. > If there are too many convenience copies this can easily outgrow the > patience (or more simply the available time) of the maintainer, at which > point repacking the upstream tarball is way simpler, easier and quicker. > It's a convenience call the maintainer decides, but one that IMHO always > ought to be done because with our current tooling removing files from > the upstream tarball is an automated process that takes seconds, where > the license check easily takes much more. FWIW the "tooling removing files from the upstream tarball is an automated process" is `uscan` and debian/copyright having a 'Files-Excluded:' entry Groeten Geert Stappers -- Leven en laten leven
Re: sarge bo rex
On Sun, Jun 24, 2018 at 05:11:45PM +0100, Adam D. Barratt wrote: > On Sun, 2018-06-24 at 18:10 +0200, Geert Stappers wrote: > > What is the sequence of Debian release names? > > > > Which Debian web page contains such list? > > > > Fairly predictably, https://www.debian.org/releases/ > Starting at https://www.debian.org/ Link on 'Release Info' Scroll beyond "stable", "testing", "unstable" and "Release life cycle" Thanks Groeten Geert Stappers -- Leven en laten leven
Re: sarge bo rex
On Sun, Jun 24, 2018 at 06:14:14PM +0200, Stephen Kitt wrote: > Hi, > > On Sun, 24 Jun 2018 18:10:49 +0200, Geert Stappers > wrote: > > What is the sequence of Debian release names? > > > > Which Debian web page contains such list? > > See https://wiki.debian.org/DebianReleases for a complete list. > Even with release and EOL dates, thanks. Groeten Geert Stappers -- Leven en laten leven
sarge bo rex
Hi, What is the sequence of Debian release names? Which Debian web page contains such list? Groeten Geert Stappers -- Leven en laten leven
Re: Debian 10 please update gimp to 2.10....
On Tue, Jun 12, 2018 at 09:48:22AM +0200, Samuel Thibault wrote: > Geert Stappers, le mar. 12 juin 2018 09:41:53 +0200, a ecrit: > > On Tue, Jun 12, 2018 at 08:36:38AM +0200, Samuel Thibault wrote: > > > DutchGigalo, le lun. 11 juin 2018 23:16:21 -0700, a ecrit: > > > > Debian 10 (buster) please update gimp to 2.10 > > > > > > gimp 2.10 is in unstable already, please be patient. > > > > Information at https://tracker.debian.org/pkg/gimp > > says there is more needed then just being patient. > > It says that users wanting it should be patient for the developers to > have a look at the issues. Thing I'm aiming for is that users[1] do more then being patient. Example given | | Hello Developers, | | GIMP, the GNU image manupilation program, | has released version 2.10 several weeks ago. | | However, it is not yet in Debian. | What could I do to make it possible? | | Yours sincerely | Joe Random | Who is fairly new to libre software | Hi Joe, Thank you for expressing your interest in this amazing eco-system called "Debian". How make it possible? As in life: Be there, find what you care about. And care about it. Stuff to read * https://en.wikipedia.org/wiki/Robustness_principle * http://www.catb.org/~esr/faqs/hacker-howto.html * http://www.catb.org/~esr/faqs/smart-questions.html * https://www.debian.org/intro/help And turn thoughts into actions. Regards Geert Stappers [1] Those who feel insulted for being a drug addict, are free to do so. -- Where did we agree that somebody else should do it?
Re: Debian 10 please update gimp to 2.10....
On Tue, Jun 12, 2018 at 08:36:38AM +0200, Samuel Thibault wrote: > DutchGigalo, le lun. 11 juin 2018 23:16:21 -0700, a ecrit: > > Debian 10 (buster) please update gimp to 2.10 > > gimp 2.10 is in unstable already, please be patient. Information at https://tracker.debian.org/pkg/gimp says there is more needed then just being patient. Regards Geert Stappers -- Where did we agree that somebody else should do it?
Re: Please remove your obsolete repos from alioth *NOW*
On Wed, May 30, 2018 at 10:41:21PM +0200, Adam Borowski wrote: > On Wed, May 30, 2018 at 06:30:20PM +0200, Alexander Wirt wrote: > > There it doesn't make sense to keep anything on alioth which is also on > > salsa. Everything else gets archived for historical purposes. > > Every repo that is on salsa and alioth will just waste ressources on the > > archive host. > > I admit I haven't been keeping track at all of repositories touched, which > were: > * copied by me from alioth to salsa > * copied by someone else from alioth to salsa, then I pointed the metadata > * I helped a non-DD create a repository on salsa to move a repo from > elsewhere (usually from a random place on alioth) > > Thus, perhaps it could be better to run a script to see if a given repo has > been copied to salsa. If such script exists, please tell. However I do think a better way is to check it Alioth "writes" are been disabled. And if so, remove the repo. [ partitial output of `ls -ltr hooks ] -rwxrwxr-x+ 1 mjj29Debian 452 sep 17 2011 applypatch-msg.sample -rwxrwxr-x+ 1 mattia Debian 48 feb 20 2016 post-receive -rwxr-xr-x+ 1 stappers Debian 86 mei 18 13:33 pre-receive stappers@moszumanska:/git/collab-maint/ipmitool.git$ umask 0022 stappers@moszumanska:/git/collab-maint/ipmitool.git$ cat hooks/pre-receive #!/bin/sh echo "Push refused." echo cat description echo echo "Thank you." exit 1 stappers@moszumanska:/git/collab-maint/ipmitool.git$ stappers@moszumanska:/git/collab-maint/ipmitool.git$ stappers@moszumanska:/git/collab-maint/ipmitool.git$ cd .. stappers@moszumanska:/git/collab-maint$ rm -rf ipmitools stappers@moszumanska:/git/collab-maint$ Groeten Geert Stappers -- Leven en laten leven
path to gitlab upstream
On Tue, May 29, 2018 at 01:04:33PM +0100, Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Want to make salsa advertise contact and source
> code details [and 1 more messages]"):
> > That seems like an horrible maintenance nightmare just to avoid even
> > talking to upstream...
>
> OK, so does someone in Debian, maybe from the Salsa team, have any
> contacts I could use ? (I promise to be reasonable and polite.)
> Or should I just try to go in through the "front door" and create an
> issue in Gitlab CE's gitlab ?
>
> ISTM that the former approach is more likely to work if we know anyone
> at Gitlab already.
There is https://gitlab.com/gitlab-org/gitlab-ce/
It has currently 10,712 issues and 595 merge requests.
About the issues: Open: 10,712 Closed: 25,941 All: 36,653
MR: Open: 595 Merged: 15,906 Closed 2,696 All: 19,198
That tells me that a Merge Request has a better success ratio.
Also that it is wise to keep notes of the MR number :-/
Groeten
Geert Stappers
--
Leven en laten leven
Re: remote: GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual "git lfs push --all".
On Wed, May 30, 2018 at 11:19:14AM +0200, Alexander Wirt wrote: > On Wed, 30 May 2018, Andreas Tille wrote: > > Hi again, :-) > > On Wed, May 30, 2018 at 07:50:01AM +0200, Alexander Wirt wrote: > > > > > Your repo has lfs disabled. You should enable it. > > > > > > > > How can I do this? > > > > I've just found[1]: "Your administrator only need to enable the LFS > > > > option." > > > *seufz* we enabled it, but as you can guess it needs to get enabled per > > > repo. > > > > > > Settings -> Permissions -> Git Large File Storage > > > > Thanks for the hint. I would not call "Permissions" the obvious place to > > look for this and my web search did not uncover this, sorry. > > > > Unfortunately it does not work yet: > use the support tracker and I will look after it when I have time. Where is that support tracker? (It feels strang to report "salsa is broken" at Salsa itself.) > debian-devel is not on the list of salsa supportchannels. Even multiple suportchannels for salsa. What are the preferred top three? In other words How cool would it be if the "not here" would have travelled with at URL you find a list of salsa supportchannels ??? Groeten Geert Stappers -- Leven en laten leven
Re: Want to make salsa advertise contact and source code details
On Fri, May 25, 2018 at 02:54:17PM +0200, Alexander Wirt wrote: > On Fri, 25 May 2018, Ian Jackson wrote: > > > > > > But, I find this response worrying. It makes me wonder whether Salsa > > is in fact really Free Software, for Debian. I don't want to suck > > energy out of the Salsa team, but: > > > > Free Software is not only a question of licences and legal > > permissions. Software is free for a particular user or group of users > > if those users can, in practice, exercise the four freedoms, including > > modifying it and using the modified version. (And yes, that means > > software freedom can be a matter of degree rather than an absolute, > > because it matters how easy it is to exercise one's freedoms.) > > > > IMO if we cannot, in practice, modify gitlab as used in Salsa, even to > > make simple changes, then it is not free software for us. > > Its not a matter of free software, but a matter of us having to support those > patches - which is something we don't want to do. Not knowing who is "we", but the thing I want to says is Do not ask for a lighter load, but ask for more shoulders to carry the load. Groeten Geert Stappers -- Leven en laten leven
Accepted libserialport 0.1.1-3 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 18 May 2018 10:44:24 +0200 Source: libserialport Binary: libserialport-dev libserialport0 Architecture: source amd64 Version: 0.1.1-3 Distribution: unstable Urgency: medium Maintainer: Debian Electronics Packaging Team <pkg-electronics-de...@lists.alioth.debian.org> Changed-By: Geert Stappers <stapp...@debian.org> Description: libserialport-dev - Crossplatform serial port handling library - development files libserialport0 - Crossplatform serial port handling library - shared library Closes: 897067 Changes: libserialport (0.1.1-3) unstable; urgency=medium . * VCS is at Salsa. * Added myself to uploaders. * Standards-Version: 4.1.4 (no changes). * Patch added to fix alpha where BOTHER is not defined (Closes: #897067). * debian/watch now also httpS. Checksums-Sha1: 574c3e13153e66c3ef0d13c83a5c737d2291371c 2124 libserialport_0.1.1-3.dsc 6f639f659b8aa0eec50a01fa06fe708743cc069f 3344 libserialport_0.1.1-3.debian.tar.xz c4f11bc508fe6bab294854921594d317cf40 405251 libserialport_0.1.1.orig.tar.gz 318761c4b42c6dda38ab8921d6edf38c508eecf1 57748 libserialport-dev_0.1.1-3_amd64.deb a7aeccc47b10dc89fda77f91a1641d40afd8f453 41776 libserialport0-dbgsym_0.1.1-3_amd64.deb 2c8ec62bf1058422e5101b1beea14d80f5873f13 44336 libserialport0_0.1.1-3_amd64.deb 948f08c0108bbf272bed6d119546a90fb531b582 6395 libserialport_0.1.1-3_amd64.buildinfo Checksums-Sha256: 6d7d4a2c88342a9c5ebfa695ec20b827af28d60f5924cece81b3975de15cee04 2124 libserialport_0.1.1-3.dsc 7918863ea8ca6aa43221c4a88fc2e504c9ac6eae13b42faf3f8ce5e96e433e88 3344 libserialport_0.1.1-3.debian.tar.xz 4a2af9d9c3ff488e92fb75b4ba38b35bcf9b8a66df04773eba2a7bbf1fa7529d 405251 libserialport_0.1.1.orig.tar.gz e742177ba2ea19a739354e9ddf38630d950a6d9f088ddc1fc12dc66fe22d2bc4 57748 libserialport-dev_0.1.1-3_amd64.deb 05f5bb5e8c87c2c53fb23f0a37896386c355aee96206f8e0ad45a9d9c42d77f1 41776 libserialport0-dbgsym_0.1.1-3_amd64.deb 11261dc1656c929be91353afbe967d88a8553fc4fb0d54541d38489af46e8178 44336 libserialport0_0.1.1-3_amd64.deb 0944ae4263398f092a9db1de49f3e56eeb961d8f1f3fedc35c7ee8c5640be7a4 6395 libserialport_0.1.1-3_amd64.buildinfo Files: a52e4072b1d14354c404b6fc9be7f454 2124 libs optional libserialport_0.1.1-3.dsc 056a5da475b2ba560d04048ac397dff1 3344 libs optional libserialport_0.1.1-3.debian.tar.xz b93f0325a6157198152b5bd7e8182b51 405251 libs optional libserialport_0.1.1.orig.tar.gz f5c7006d800f92331bccc95d78d14b81 57748 libdevel optional libserialport-dev_0.1.1-3_amd64.deb 62688303d318ad2722ccb2a37853fbfd 41776 debug optional libserialport0-dbgsym_0.1.1-3_amd64.deb 9460c95aa5a36ff0929eed0af507e72f 44336 libs optional libserialport0_0.1.1-3_amd64.deb 70c2d1abbbeb681777b8416777a346a8 6395 libs optional libserialport_0.1.1-3_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEin8gjG2ecykWV0FNITXRI9jBm+wFAlr+orgACgkQITXRI9jB m+yPxRAApfJ0S2JJ1Lw3qc/01g61cUQLuDXFyiwgfXCL3qWAumIq6+Hv2VDMJytE ceU4381jt8JUMRDLBGnOiNiIfIXpkWq4cKIRcDwFzuS1wuBfMtoHhLjEn+PDgBpS /Ld/oSctWkWQmWXXME6KyInI+kDfI7KQR/evS7R4msoiNirvNg17flcQcPRV+XgV 7YZYP7pgm0MYs84AHLUDO4KXC5Axp0EhYL2/LwccgrvfdErCF3jxpCxU6viX8Eo5 OqpxO3yLmy/GQQBA6js1neW3XluGzajJopsy2WgWb9S6V5ilAeN8Crb3Ki4+HdZN P1VTxcvLIymrU3ikAEavk11A5+XIFsQ3eW7qKUkg4hFsCI/2TudjxPVPWO4yrf0A BfMrmngJc5JKoKUifSjqhl0WgzpuyoPDnt2zB6r1f2U7LInSnyiCK38B26CC03ZA cO3Qpsxm2PQareBDFelnocV/70NfX2YPJonWwYY7C5ldTkO7j1tr9JD4QfUe/Rrm B6hjuEZH3IoUJUnHmLl8y5lFgkk0C99w+qOfs7PWyVM5+UOQWWKsnXJgFPCFd8eE N+WsILjlrUONpterBDTx6KoRfaeeBtwOyMEhPZduvPdLcDJm2AgwAUJu1G0Z650U 0FiGe8hPUg9bBB3muqZIGklNUWc3bc4WNShpyX8dY5L24HC2/sk= =wHvD -END PGP SIGNATURE-
When pkg-foo is not at all involved here
Hello debian-devel, IIRC do we agree that feedback is good. On Sun, May 13, 2018 at 04:51:54PM +0200, Michael Biebl wrote: > [always CC the package maintainer when reassigning] https://lists.debian.org/debian-devel/2018/05/msg00243.html > On Sun, 13 May 2018 15:58:01 +0200 Geert Stappers wrote: > > Control: reassign -1 network-manager-gnome https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898394#37 > > Hello, > > > > Bug was report against package "general". > > Package 'network-manager-gnome' seems a better fit. > > Most certainly not, as network-manager-gnome is not at all involved here. > Yeah, that is where the pain is, the spot that needs improvement. I think we have all been there: Encounters with a software bug, feeling the need to report it, but not knowning _how and where_ to report. We shall never know how many times people _choose to not report_. In #898394 we did get report of a possible software bug, filed against package "general". What can we do better to get bugreports^Wfeedback at the right place? Groeten Geert Stappers -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? Having a plan B is considered a wise option. ;-)
Bug#898394: screen shots next to each other
Find attached the two screenshots next to each other in one image. Groeten Geert Stappers
Bug#898394: assign to GNOME Network Manager package
Control: reassign -1 network-manager-gnome Hello, Bug was report against package "general". Package 'network-manager-gnome' seems a better fit. Cheers Geert Stappers
Bug#898394: [keyikedalubend...@protonmail.ch: Re: Bug#898394: Network icon]
- Forwarded message from keyikedalubend...@protonmail.ch - Date: Fri, 11 May 2018 20:56:10 -0400 From: keyikedalubend...@protonmail.ch To: Geert Stappers <stapp...@stappers.nl> Subject: Re: Bug#898394: Network icon Flight mode or without, the network icon does not update. Notice that "Ethernet connected" below? It's icon is diferrent from the network icon on the panel. Both should be the same. But the two images only indicate "still connecting" status even after my computer is already connected. [ Original Message ] - End forwarded message - Groeten Geert Stappers -- Leven en laten leven
Bug#898394: Network icon
On Fri, May 11, 2018 at 10:05:36AM -0400, keyikedalubend...@protonmail.ch wrote: > Below is two attached images. > One depicting when on flight mode and the other without flight mode on. The 19:31:35 PNG has a airplane symbol, the other not. I fail to see how the provided images add value to original reported problem. @keyikedalubendang is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898394 about a not updated icon or is it about "'flight mode' versus 'normal mode'"? Groeten Geert Stappers -- Leven en laten leven
Bug#898394: general: Network (Ethernet) icon not updating on connection
Control: tag -1 moreinfo On Fri, May 11, 2018 at 09:53:43AM +0530, Keyikedalube Ndang wrote: } on my notebook I'm noticing that > the network icon does not update even the connection is successful. It usually > keeps displaying that connecting status; the icon is grayed out. > > Rarely, the icon is displayed correctly i.e., it's no longer grayed but shows > white icon (successful connection) > Please make a partial screenshot that contains the icon, white or grey. Attached is an example. It is the upper-right corner of a Debian XFCE installation. Cheers Geert Stappers
Re: Announce: docker-buildpackage
On Tue, May 01, 2018 at 09:41:13PM +0800, Paul Wise wrote: > On Tue, May 1, 2018 at 9:23 PM, Enrico Weigelt, metux IT consult wrote: > > > I've written a tool for isolated deb builds in docker containers. > > It's a little bit like pbuilder, but using docker for isolation. > > > > https://github.com/metux/docker-buildpackage > > Does it have any advantages over whalebuilder? > https://tracker.debian.org/pkg/whalebuilder Homepage: https://www.uhoreg.ca/programming/debian/whalebuilder Debconf talk: https://debconf17.debconf.org/talks/84/ Groeten Geert Stappers -- Leven en laten leven
