Re: Is missing SysV-init support a bug?
On Mon, 29 Aug 2016 20:18:49 -0700, Russ Allbery wrote: >Debian historically tries to handle these situations by just providing >everything simultaneously. The debate over init systems is as heated as >it is because it's quite difficult to do a good job at supporting multiple >init systems. And because it's a system-wide decision. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
GPL debate on kernel mailing list
Hi, http://www.jonobacon.org/2016/08/29/linux-linus-bradley-open-source-protection/ just popped up in my rss feed and I thought I'd share it with you… it's a comment on the recent GPL enforcement debate on the (upstream) kernel list. I basically agree with Jono here. -- cheers, Holger signature.asc Description: Digital signature
libsystemd
Dmitry Bogatov: Thanks history, we have pid files, not `libpid' to talk to `pidd'. You have forgotten about the existence of Debian Hurd. (-: * https://jdebp.eu./FGA/hurd-daemons.html#proc
Re: Is missing SysV-init support a bug?
Marc Haber writes: > Russ Allbery wrote: >> Debian historically tries to handle these situations by just providing >> everything simultaneously. The debate over init systems is as heated >> as it is because it's quite difficult to do a good job at supporting >> multiple init systems. > And because it's a system-wide decision. Yeah, that too, although I think that's somewhat less of a factor. (But it is a factor.) Choosing your MTA or your cron daemon is also a system-wide decision, but Debian supports tons of them and it's no big deal. The init system has several tricky factors, though: 1. Init systems by their very nature integrate with huge classes of software in the rest of the distribution, which is what makes it quite difficult to do a good job at supporting multiple init systems since there's quite a lot of work to do for each of them. It's not quite as bad as supporting building Debian with multiple C compilers, but it's in that ballpark. 2. It's something that any experienced sysadmin is going to have to mess with, so it's not just something that Debian has to integrate, it's also something that has a lot of careful, tricky custom configuration done by the local administrator. Who is obviously going to have strong opinions about how they work with it. 3. In the Debian context, it was a particularly stable (or stale, depending on how you want to spin it) part of the distribution. Ubuntu had upstart, Red Hat had played with other init systems, but Debian largely hadn't. So none of the muscles around "oh, this doesn't have to work exactly this way" were really being exercised. (Yes, there was file-rc and a few other things, but the level of usage was miniscule.) So it's a wrenching transition to consider something else. 4. Managing daemons is something about which many of us have Opinions. Strong Opinions. Please allow us to relate them to you. They are quite Strong, and are Very Important, and we have Thought About Them A Great Deal, and your opinions, if they differ, are probably Wrong. Managing daemons is to sysadmins what editors are to programmers. We spend lots of time with that software. Opinions form. 5. It is arguable what the init system can or should do. By that, I mean that some people think the init system should do quite a lot more than it historically had done, because there was a bunch of stuff being done poorly and inconsistently that benefits greatly from being standardized. And other people who believe that, if anything, the problem with sysvinit was that it was doing too much and was too complex. And neither of these people are obviously wrong. Depending on what angle you look at things from, you can make a lot of strong arguments all around. It's much like the debate between writing software in some very high-level language like Python versus writing it in C, as mentioned in my other message. 6. systemd muddled this considerably because it's not only an init system project, it's an operating system plumbing project whose contributors are very excited to fix what they view as a wide variety of historical warts and suboptimal solutions to a ton of various low-level plumbing and integration issues. This is simultaneously exciting and scary. (And I'm going to go out on a limb here and say that if you find it only exciting, or if you find it only scary, you are not thinking enough about it, are missing significant components of this effort, and should really think about it some more until you can recognize both halves of that reaction and why they both make sense.) There is a bunch of low-level plumbing deep inside UNIX and Linux that is, to be frank, archaic, cobbled-together bullshit, and that I think we'd all admit was that if it came up in a context outside of a very heated and divisive debate. Modern thinking on component separation, configuration syntax, APIs, and the usefulness of things like event buses are, shall we say, informed by decades of experience, much broader communities and more varied goals, and a huge developer base, compared to what the original designers of UNIX had available. It's not at all hubris to look at the icky guts of OS plumbing, particularly the bits that were never really designed but just accreted over the years, and think "this could be a lot better if it were properly designed for modern systems and problems." But change sucks, and part of what accreted was decades of subtle workarounds to poorly-documented issues for which we have minimal institutional memory. If contemplating replacing that stuff doesn't terrify you from a stability and disruption standpoint, you're not thinking about it hard enough. 7. systemd upstream sits at the perfect inflection point between insufficiently good at communication and interpersonal politics to be easy for e
Re: libsystemd
Jonathan de Boyne Pollard, on Tue 30 Aug 2016 08:55:26 +0100, wrote: > >Thanks history, we have pid files, not `libpid' to talk to `pidd'. > > > You have forgotten about the existence of Debian Hurd. (-: The Hurd precisely tries to expose things as files. Samuel
Re: libsystemd
[2016-08-30 08:55] Jonathan de Boyne Pollard > > part text/plain 198 > Dmitry Bogatov: > > > Thanks history, we have pid files, not `libpid' to talk to `pidd'. > > > You have forgotten about the existence of Debian Hurd. (-: I like Hurd idea, but I was talking about Linux kernel and userspace above it. -- Accept: text/plain, text/x-diff Accept-Language: eo,en,ru X-Web-Site: sinsekvu.github.io
Re: libsystemd [was: Re: Is missing SysV-init support a bug?]
[2016-08-29 18:30] Russ Allbery > > part text/plain1918 > Dmitry Bogatov writes: > > > Socket is not bad thing. Inventing daemon for no reason is complicating > > things for no reason => bad. Thanks history, we have pid files, not > > `libpid' to talk to `pidd'. > > Uh, the daemon in question is the init daemon? Which has been there since > the beginning of UNIX? You kind of need that daemon. You can't do > without it. :) I know that pid 1 is daemon, that one must have. And this daemon, for sake of simplicity, should just boot system. I do not buy your argument, that since we already have daemon, lets just put another optional functionality in it. > PID files are an ugly hack and have *always* been an ugly hack. I cannot > tell you the number of obnoxious edge cases I've had to deal with around > PID files: files getting created at the wrong time, with the wrong > ownership, in directories that aren't writable by the process and > therefore fail, with invalid contents, or truncated, or reused for some > other purpose and now with bizarre and undocumented syntax, or kept around > after the host reboots and they become irrelevant, or used entirely > unsafely because the original daemon is long-gone, the PID space has > wrapped, and now that PID is pointing to sshd and gets happily killed by > something that blindly trusts the PID file. They're not something anyone > would want to use voluntarily. I agree, that pid-files are not blessing, especially when we have runit/daemontools/s6, which makes them unneeded. But if I had to choose between pidfiles or linking to `libpid' to talk with `pidd' (especially, if it is part of pid 1), I would choose pidfiles. > > I would be interested to know of more selling points of libsystemd, but > > discussion how to implement them in simple way does not belong to > > debian-devel, but to upstream projects lists. > > I'm discussing it on debian-devel because so many of the arguments against > systemd on the grounds of its supposed contrariness to UNIX demonstrate > the most appalling ignorance of UNIX, and I think it's useful to talk > about *specifics* instead of general political positions on systemd as an > abstract Platonian ideal. We're making a free UNIX distribution. We > should care *deeply* about the specifics; that's the best way to make good > decisions. And we should be connoisseurs of good ideas, whatever their > source. -- Accept: text/plain, text/x-diff Accept-Language: eo,en,ru X-Web-Site: sinsekvu.github.io
Bug#809158: ITP: gajim-plugin-omemo -- Gajim plugin for OMEMO Multi-End Message and Object Encryption
retitle 809158 ITP: gajim-plugin-omemo -- Gajim plugin for OMEMO Multi-End Message and Object Encryption thanks Update: New homepage, new version * Package name: gajim-plugin-omemo Version : 0.9.0 / 2016-08-28 Upstream Author : Bahtiar Gadimov * URL : https://github.com/omemo/gajim-omemo * License : GPL3+ Programming Lang: Python Description : Gajim plugin for OMEMO Multi-End Message and Object Encryption The author does not declare the plugin as experimental anymore, so from my POV it is potentially ready for Debian. Note: GitHub shows 0.8 as latest release, but CHANGELOG has advanced.
libsystemd
Russ Allbery: I think that... says the same thing I said? Read again, and let your eye dwell upon Laurent Bercot's name this time. (-: The world has changed since 2014 and the Debian systemd packaging Hoo-Hah, and I've been keeping tabs. * https://jdebp.eu./FGA/unix-daemon-readiness-protocol-problems.html#Choice * http://skarnet.org/software/s6-rc/ * http://skarnet.org/software/s6-linux-init/ * https://github.com/OpenRC/openrc/blob/HEAD/s6-guide.md * https://news.ycombinator.com/item?id=11675129 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 * http://www.mail-archive.com/supervision@list.skarnet.org/msg01351.html * https://tracker.debian.org/pkg/runit * https://lists.debian.org/debian-user/2016/08/msg00182.html * https://www.freebsd.org/news/status/report-2015-10-2015-12.html
Re: GPL debate on kernel mailing list
On 08/30/2016 09:43 AM, Holger Levsen wrote: > Hi, > > http://www.jonobacon.org/2016/08/29/linux-linus-bradley-open-source-protection/ > just popped up in my rss feed and I thought I'd share it with you… it's > a comment on the recent GPL enforcement debate on the (upstream) kernel > list. > > I basically agree with Jono here. > > For years and years companies are using community hard work and creating their "great" products without turning back. Not only they don't comply with Freedom licenses, they are even creating atmosphere that proprietary product is always of higher quality and better support compared to FLOSS ones, yet you daily find that they shamelessly built almost entire product with FLOSS stack (even if they added some third-party proprietary stack it is a good chance that third-party is also built with large chunks of FLOSS stack). And it is not like they choose it by mistake. They choose GPL on purpose and violate it on purpose. There are numerous other licenses they can choose and not violate, yet they choose GPL and violate it. The last resort situation was already decade ago (and I am not even mentioning here patent trolls that tried to invade FLOSS communities with their law pressures) so I don't see the point of talking about taking any other approach. Linux Foundation is corporation (you can call it non-profit consortium and use all other buzz words, but it effectively is business and large corporation), and it is getting big sponsorships from proprietary companies. Linus gets paycheck from it so he naturally defends it. It is human instinct to do so, because it brings food on your table. I understand that, but as with every other organization that thinks they know best, deal is - even if all your members think the same, you're still not benefiting larger community that you assume you represent nor do you comply with what larger community expects. People all over the world created Free software for decades and just small number of those people got employed to work on Free software for living, so when companies take fruit of their work and violate the core idea behind it - then we are automatically at last resort and I am thankful that at least one organization tries to protect and enforce such idea compared to all others who simply either don't care or violate it. Free software is also a social movement that we need to protect, share and show people and with all violators and mindset that is going on in trying to show that only way to do things or create "great" things is proprietary I can only see dark ages and not progress. I don't know is it a time for GPLv4 which will explain to all corporations that THIS LICENSE mean you must participate with community and also make people aware that it is not only license but movement towards better humanity that cooperates all the time in all fields without fear of being left out or not earning enough for decent life and not engage that only way to achieve is by lies, manipulation, abuse, FUD, secrets. Lets not repeat history here but be proactive in defense of our and our users rights. My (valuable) 15mins, -- Zlatan Todorić Proud Debian Developer .''`. : :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: OpenPGP digital signature
Re: Is missing SysV-init support a bug?
Russ, On Tue, Aug 30, 2016 at 01:24:44AM -0700, Russ Allbery wrote: [...] > It's kind of a perfect storm. It makes sense if you sit down and > enumerate the reasons, but it's still kind of amazing just how much of a > perfect storm it is. *g* [...] > TL;DR: I fear this init system is going to go on forever nah, nothing is forever! :-) 5, 10 or 15 years maybe, I hope… [...] > But I do wish that people would acknowledge more of the above nuance when > having this argument, and realize that the last thing we should ever do is > claim that this decision is clear-cut or black and white. Yes. Thanks a lot for taking the time to write this down. Except for the tiny "forever" bit I much agree with what you wrote… -- cheers, Holger signature.asc Description: Digital signature
freeradius needs a new maintainer
[ Bcc debian-mentors ] Hello, following the recent discussions in #806617 it has become apparent that we need a new maintainer for freeradius. Debian still has version 2.2.x when upstream is now on 3.0.x. Is there anyone interested? It would be a pity to see freeradius gone from Debian. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: freeradius needs a new maintainer
On 30/08/16 14:43, Raphael Hertzog wrote: [ Bcc debian-mentors ] Hello, following the recent discussions in #806617 it has become apparent that we need a new maintainer for freeradius. Debian still has version 2.2.x when upstream is now on 3.0.x. Is there anyone interested? It would be a pity to see freeradius gone from Debian. Cheers, Hi, I'm currently not an active maintainer within Debian, but freeradius is essential (also to what i do), so I will have a go at it. Kind regards, Martin List-Petersen
Re: freeradius needs a new maintainer
>Hi, >I'm currently not an active maintainer within Debian, but freeradius is >essential (also to what i do), so I will have a go at it. >Kind regards, >Martin List-Petersen Hello, I'm also interested. I wanted to get into being a Debian Maintainer for a long time. I think this could be the right opportunity for it! I know Alessio Treglia personally and he agreed to sponsor me on this. What do you think? Thanks Vito Mule'
Re: libsystemd
]] Jonathan de Boyne Pollard > Russ Allbery: > > > I think that... says the same thing I said? > > > Read again, and let your eye dwell upon Laurent Bercot's name this > time. (-: The world has changed since 2014 and the Debian systemd > packaging Hoo-Hah, and I've been keeping tabs. s6 doesn't seem to be in Debian and falls under Russ' «That said, my statement is almost certainly wrong in that it doesn't take into account the many less well-known init systems, some of which almost certainly have something like this that I'm not familiar with.» clause. Until it's packaged, I think it's pretty irrelevant to our discussions here. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Porter roll call for Debian Stretch
Sorry for the previous post without signature. Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the Stretch release (est. end of 2020): For mips, mipsel and mips64el, I - test most packages on this architecture - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - maintain buildds - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) - run other automated tests outside the Debian QA services Run daily build test Run autopkgtest - ... I am a DD I believe the ports *are* ready to have -fPIE/-pie enabled by default. YunQiang Su > 在 2016年8月31日，00:04，YunQiang Su 写道： > > Hi, > > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the Stretch release (est. end > of 2020): > > For mips, mipsel and mips64el, I > - test most packages on this architecture > - run a Debian testing or unstable system on port that I use regularly > - fix toolchain issues > - triage arch-specific bugs > - fix arch-related bugs > - triage d-i bugs > - test d-i regularly > - fix d-i bugs/issues > - maintain buildds > - maintain/provide hardware for (or assist with) automated tests on ci.d.n, >jenkins.d.n (etc.) > - run other automated tests outside the Debian QA services > Run daily build test > Run autopkgtest > - ... > > I am a DD > > I believe the ports *are* ready to have -fPIE/-pie enabled by default. > > YunQiang Su > > On Sun, Aug 28, 2016 at 11:53 PM, Aurelien Jarno wrote: >> On 2016-08-17 22:05, ni...@thykier.net wrote: >>> Hi, >>> >>> Like last release, we are doing a roll call for porters of all release >>> architectures. If you are an active porter behind one of the [release >> >> Does it really concerns *all* release architectures? Traditionally amd64 >> and i386 have been granted waivers as "the toolchain maintainers are >> happy to support" these architectures "as-is". That said the toolchain >> maintainers do not fix ports specific bugs outside of the toolchain. >> >> While I fully agree that we can have a waiver for amd64 due to being the >> de facto standard architecture, it seems that a few leaf packages do >> not build on i386 and that we have no porters to fix them. That is >> probably still fine, but I wonder how fast the number of such packages >> will increase in the future. >> >>> architectures] for the entire lifetime of Debian Stretch (est. end of >>> 2020), please respond with a signed email containing the following >> >> What is the relation between the end of support of Stretch... >> >>> before Friday, the 9th of September: >> >>> * Which architectures are you committing to be an active porter for? >>> * Please describe recent relevant porter contributions. >>> * Are you running/using Debian testing or sid on said port(s)? >>> * Are you testing/patching d-i for the port(s)? >>> * If we were to enable -fPIE/-pie by default in GCC-6, should that change >>> also apply to this port? [0] >> >> ... and the above questions? >> >> I fully agree that running testing/sid, fixing bugs or working on d-i up >> to the release of Stretch will improve its quality. But after the >> release it will improve the quality of Buster and later Bullseye. On the >> other hand running testing/sid after the release of Stretch will not >> help to catch bugs that can be fixed through a point release. >> >> Aurelien >> >> -- >> Aurelien Jarno GPG: 4096R/1DDD8C9B >> aurel...@aurel32.net http://www.aurel32.net > > > > -- > YunQiang Su signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Porter roll call for Debian Stretch
Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the Stretch release (est. end of 2020): For mips, mipsel and mips64el, I - test most packages on this architecture - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - maintain buildds - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) - run other automated tests outside the Debian QA services Run daily build test Run autopkgtest - ... I am a DD I believe the ports *are* ready to have -fPIE/-pie enabled by default. YunQiang Su On Sun, Aug 28, 2016 at 11:53 PM, Aurelien Jarno wrote: > On 2016-08-17 22:05, ni...@thykier.net wrote: >> Hi, >> >> Like last release, we are doing a roll call for porters of all release >> architectures. If you are an active porter behind one of the [release > > Does it really concerns *all* release architectures? Traditionally amd64 > and i386 have been granted waivers as "the toolchain maintainers are > happy to support" these architectures "as-is". That said the toolchain > maintainers do not fix ports specific bugs outside of the toolchain. > > While I fully agree that we can have a waiver for amd64 due to being the > de facto standard architecture, it seems that a few leaf packages do > not build on i386 and that we have no porters to fix them. That is > probably still fine, but I wonder how fast the number of such packages > will increase in the future. > >> architectures] for the entire lifetime of Debian Stretch (est. end of >> 2020), please respond with a signed email containing the following > > What is the relation between the end of support of Stretch... > >> before Friday, the 9th of September: > >> * Which architectures are you committing to be an active porter for? >> * Please describe recent relevant porter contributions. >> * Are you running/using Debian testing or sid on said port(s)? >> * Are you testing/patching d-i for the port(s)? >> * If we were to enable -fPIE/-pie by default in GCC-6, should that change >>also apply to this port? [0] > > ... and the above questions? > > I fully agree that running testing/sid, fixing bugs or working on d-i up > to the release of Stretch will improve its quality. But after the > release it will improve the quality of Buster and later Bullseye. On the > other hand running testing/sid after the release of Stretch will not > help to catch bugs that can be fixed through a point release. > > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net -- YunQiang Su
Re: Porter roll call for Debian Stretch
Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the Stretch release (est. end of 2020): For ppc64el, I - test most packages on this architecture - run a Debian testing or unstable system on port that I use regularly - triage arch-specific bugs - fix arch-related bugs - test d-i with some regularity - am currently woking on providing ppc64el hardware so to include the arch to ci.d.n I am not a DD/DM. I believe the port is ready to have -fPIE/-pie enabled by default. Fernando Seiti Furusato signature.asc Description: OpenPGP digital signature
Bug#836133: ITP: credential-sheets -- User account credential sheets tool
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: credential-sheets Version : 0.0.2 Upstream Author : Mike Gabriel * URL : https://github.com/sunweaver/credential-sheets * License : GPL Programming Lang: Perl Description : User account credential sheets tool After mass import of user accounts (e.g. into LDAP) most site administrators have to create information sheets (or snippets) containing those new credentials (like username, password, policy of usage, etc.). With this tiny tool, providing these pieces of information to multiple users, becomes really simple. Account data is taken from a CSV file and the sheets are output as PDF using easily configurable LaTeX template files. This package will be maintained under the umbrella of the Debian Edu Packaging Team.
Re: Porter roll call for Debian Stretch
On 22/08/16 at 19:12 +0200, Bálint Réczey wrote: > Hi Guillem, > > 2016-08-21 14:02 GMT+02:00 Guillem Jover : > > Hi! > > > > On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote: > >> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for > >> all > >> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu. > >> > >> My assumption was that this set of architectures need the least amount of > >> additional work since they are tested already in Ubuntu, but I would be > >> happy > >> if more ports would opt in for PIE. > >> > >> I plan filing wishlist bugs against dpkg and gcc with the patches > >> after I rebuilt a > >> few packages with the defaults. > > > > TBH I think PIE should in fact be safer to enable globally than > > bindnow, because the latter changes the run-time behavior and things > > might break (perhaps even silently) when failing to load plugins > > or similar. > > Yes, in that sense enabling PIE is safer indeed. Regarding bindnow > I don't expect too many surprises either, since other distributions > already tested enabling bindnow and probably they found > most issues. > > > > > From dpkg PoV enabling both, would at least require a full-archive > > rebuild, for bindnow ideally also a full autopkgtest run (as the > > updated dpkg FAQ states now, after Lucas Nussbaum approached me some > > weeks ago mentioning he was willing to do such archive-wide rebuild). > > The patches at [2] seem to work well and since you expressed that you would > prefer changing both toolchain and dpkg, too, I would like to suggest running > the rebuild with those patches. > > I think Matthias would be OK with the patch since it is very small and brings > Debian's gcc closer to Ubuntu's. > > Lucas, could you please run the rebuild with the three patches? Hi, Results are available at https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/ I did a full rebuild with bindnow and PIE enabled, then rebuilt all failed packages with a pristine unstable chroot. You can take a look at https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt and grep for "OK Failed" (failed with PIE+bindnow, built fine in unstable). (There are 1188 packages failing to build) Logs for both builds are available in the respective subdirectories. Lucas
Re: removal instead of orphaning?
Hello, On Tue, Aug 30, 2016 at 10:20:21AM +0800, Paul Wise wrote: > On Tue, Aug 30, 2016 at 1:56 AM, Niels Thykier wrote: > > > Frankly, I do not think that the source package is the correct place for > > the Maintainer / Uploaders data. There are plenty of cases where it > > would make sense to update it "retroactively" after the package has been > > uploaded (E.g. orphaned or adopting without an upload). > > Indeed. Same for Homepage and watch files. The nice thing about the homepage being there is that the user can get it by running `apt-cache show foo`. Unless you plan to pull in that information when building the binary package? Is your reason for not including the watch file primarily because it doesn't make sense that updating it requires a new source package revision? -- Sean Whitton
Re: freeradius needs a new maintainer
Hello, On Tue, Aug 30, 2016 at 02:56:07PM +0100, Martin List-Petersen wrote: > I'm currently not an active maintainer within Debian, but freeradius is > essential (also to what i do), so I will have a go at it. On Tue, Aug 30, 2016 at 05:21:17PM +0200, Vito Mulè wrote: > I'm also interested. > > I wanted to get into being a Debian Maintainer for a long time. I > think this could be the right opportunity for it! > > I know Alessio Treglia personally and he agreed to sponsor me on this. I suggest you get Alessio to get both of you access to Debian's collab-maint git repository hosting area, and co-maintain the package in a git repository there. -- Sean Whitton
Re: removal instead of orphaning?
On Wed, 2016-08-31 at 00:19 +, Sean Whitton wrote: > The nice thing about the homepage being there is that the user can get > it by running `apt-cache show foo`. Unless you plan to pull in that > information when building the binary package? It woudn't need to be present when building the binary package for it to be present in the output of `apt show`, dak could pull it from whatever service it is maintained in and add it to the apt metadata. > Is your reason for not including the watch file primarily because it > doesn't make sense that updating it requires a new source package revision? The contents of Maintainers, Homepage, debian/watch, debian/upstream/* and possibly other information can change independently of the source package so it makes sense to not maintain them in the source package. Personally I think Debian is too attached to the current model of storing everything in the source package (and increasingly in git) to be able to change to external maintenance of these things soon. That said, we do have separate watch file maintenance already: https://alioth.debian.org/projects/sepwatch/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
