On Sat, Apr 6, 2019 at 2:50 PM Guillem Jover wrote:
> I noticed that not all big desktop programs support Wayland natively
> (such as Chromium)
Patches for chromium would be very welcome [0], but it is of course
too late for buster.
Best wishes,
Mike
[0] http://bugs.debian.org/861796
On Mon, Dec 31, 2018 at 1:06 PM Ben Hutchings wrote:
> At the risk of bikeshedding, some alternate names that might be less
> confusing:
>
> - fresh-apps
> - evergreen
> - rolling-apps
At further risk of bikeshedding, how about "sideports"?
1. Uses a metaphor rather similar to backports.
2. Sorts
control: reassign -1 src:steam
control: retitle -1 steam: fails to load libGL.so.1
Make sure you have either libgl1-mesa-glx:i386 or your proprietary
driver's i386 glx package installed. See bug #718599.
Best wishes,
Mike
On Wed, Mar 28, 2018 at 2:24 PM, Adrian Bunk wrote:
> The core problem is that in the control file the permitted syntax for
> the Architecture: filed is much more restricticted than the permitted
> syntax for (build) dependencies.
This is dpkg bug #807264.
Best wishes,
Mike
On Sat, Jun 24, 2017 at 7:44 AM, Michael Biebl wrote:
> Given how long init-select has been RC buggy, I wonder if it wouldn't be
> better to remove it from the archive completely. Selecting a fallback
> init is something grub already provides today, so I don't see
> init-select as something useful
On Fri, Feb 24, 2017 at 10:05 AM, Ian Jackson wrote:
> It seems likely to me that this is a bug, not some kind of
> "ideological mistake".
You basically nailed it, especially since I don't care either way [0].
People are yelling must have safe defaults on one side.
And people are yelling must hav
On Wed, Sep 23, 2015 at 12:20 PM, Mattia Rizzolo wrote:
> On Wed, Sep 23, 2015 at 11:30:55AM -0430, PICCORO McKAY Lenz wrote:
>> There's any consensus around quakeworld packagin?
>
> I don't hold a clue. Also you removed debian-devel@ from CC, so it's
> quite improbable somebody will reply to you.
On Sat, Aug 29, 2015 at 7:10 AM, Stefano Zacchiroli wrote:
>> On the other hand that state went on for years and we should be able
>> to form our own opinion about freeness and how to abide to our
>> commitment to users and free software.
>
> We have formed our own opinion. Repeatedly, over many ye
On Sun, Jul 5, 2015 at 12:29 AM, lumin wrote:
> For example, the Chromium:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909
> What if we constantly keep feeling free to use non-free blobs,
> and get compromised with those suspicious weird binary blobs,
> and those odd software behaviours
On Thu, Jun 18, 2015 at 8:57 PM, Christoph Anton Mitterer wrote:
> On Thu, 2015-06-18 at 20:36 -0400, Michael Gilbert wrote:
>> See previous message.
> I've had read that only afterwards, as well as this message.
>
>
>> You will get
>> absolutely nowhere continui
On Thu, Jun 18, 2015 at 8:23 PM, Christoph Anton Mitterer wrote:
> - still no DSA (or something like that)
See previous message.
> - still no concentrated effort at the Debian level to pro-actively work
> against such sources that include or more or less secretly download
> blobs
If you have an
On Wed, Jan 21, 2015 at 9:41 PM, Russell Stuart wrote:
> The reason is all that happens now is you get one unwanted email and
> that is the end of it. In particular the attacker can't force you do to
> something to prevent the bugs.debian.org from sending further unwanted
> emails. If you get rid
On Mon, Jan 19, 2015 at 7:32 PM, Russell Stuart wrote:
> In other words the current system contains robust defences against such
> an attack. All I (and I presume Ben) are saying is removing those
> defences is not a good idea, given it's easy enough to design a system
> that keeps them. Currentl
On Mon, Jan 19, 2015 at 4:41 AM, Russell Stuart wrote:
>> But isn't subscribing participants "natural"?
>
> It may be natural, but IMO you are underestimating the spam vector
> problem.
>
> Debian's bug submission mechanism does not try to verify you control the
> email address you are submitting f
On Sun, Dec 21, 2014 at 9:11 AM, Bálint Réczey wrote:
>> The problem still remains that the backlog of libv8 security issues
>> never get fixed (except for a new upstream every now and then), so
>> treating this one as RC but not the others is rather inconsistent:
>> https://security-tracker.debian
On Sat, Dec 20, 2014 at 7:52 PM, Bálint Réczey wrote:
> The proper severity of this bug is grave as set by Moritz IMO. I'm
> restoring it wearing my maintainer hat.
It's not really constructive arguing over severity, so that's fine.
You've saved yourself from needing to write an unblock request.
On Sat, Dec 20, 2014 at 6:15 AM, Adam D. Barratt wrote:
> On Sat, 2014-12-20 at 11:48 +0100, Jonas Smedegaard wrote:
>> [sent again, cc correct list address this time]
>>
>> Quoting Michael Gilbert (2014-12-20 11:06:47)
>> > On Sat, Dec 20, 2014 at 4:59 AM, Balint
On Sun, Nov 9, 2014 at 10:10 AM, Ralf Jung wrote:
> I read Joey's message over and over without getting any more clues. He
> said the CTTE has "Decided it should make a decision", which it seems to
> me it did not. So I probably misunderstood something more fundamental here.
Read all of #762194 ve
On Sun, Nov 9, 2014 at 12:01 AM, Christoph Anton Mitterer wrote:
> On Sat, 2014-11-08 at 23:30 -0500, Michael Gilbert wrote:
>> No accusation, just a statement of fact. Four ctte members were
>> complicit in the vote [0]
>
> Well maybe I read that ruling wrong, but didn&
On Sat, Nov 8, 2014 at 10:57 PM, Christoph Anton Mitterer wrote:
> On Sat, 2014-11-08 at 22:32 -0500, Michael Gilbert wrote:
>> You are one of four
>> complicit in the act that finally pushed Joey over the edge [0].
>
> Don't you think it goes a bit far to personally accu
On Sat, Nov 8, 2014 at 10:53 PM, Russ Allbery wrote:
> I don't want this to be taken as asking for criticism to be shut down, so
> I'm not asking this of anyone who wants to agree with Michael. If you
> want to do that in public or private, please go ahead. But I would
> greatly appreciate not be
On Sat, Nov 8, 2014 at 8:08 PM, Russ Allbery wrote:
> zlatan writes:
>
>> In advance sorry for all spelling mistake that I will write as I am
>> writing from my phone and I am not a native English speaker.
>
> [...]
>
> And yet, I don't see how it could have been said better. Thank you so
> much f
On Thu, Oct 30, 2014 at 1:12 AM, Russell Stuart wrote:
> On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote:
>> Also, this means that you completely miss security advisories that *don't*
>> involve changing a package in the archive, like "this thing is a disaster,
>> so we're pulling it from the
On Thu, Oct 30, 2014 at 12:09 AM, Christoph Anton Mitterer wrote:
> On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote:
>> Packages appearing on mirrors is not how we notify Debian users of
>> security updates. We do that by issuing a security advisory.
> Aha,... well... sounds like nitpicking,
On Sun, Sep 14, 2014 at 2:47 AM, Sébastien Villemot wrote:
> The bottom line is that julia needs SSE2 (and porting it to the x87 FPU
> requires changes that are beyond what I am willing/able to do, see [1]
> for more details). And the presence of SSE2 is not guaranteed on the
> i386 architecture.
pam_timestamp module (closes: 757555)
+
+ -- Michael Gilbert Sat, 09 Aug 2014 09:50:42 +
+
pam (1.1.8-3) unstable; urgency=low
* debian/rules: On hurd, link libpam explicitly with -lpthread since glibc
diff -u pam-1.1.8/debian/patches-applied/series pam-1.1.8/debian/patches-applied/ser
On Sat, Aug 9, 2014 at 7:34 AM, Andreas Cadhalpun wrote:
> It's probably not necessary to make a new upload to the NEW queue for this
> change. In the repository is a new upstream version anyway and it will be
> uploaded, once the current version gets accepted.
Based on the license review, you sho
On Fri, Aug 8, 2014 at 12:00 PM, Marco d'Itri wrote:
>> If the xfce iso didn't exist, people in these situtations would
>> not be able to install a usable Debian system.
> I see a solution that would satisfy everybody: whoever is interested in
> supporting this kind of situations could build CD ima
On Fri, Aug 8, 2014 at 1:52 AM, Michael Gilbert wrote:
> The better question is whether the xfce switch had or has any
> influence on slowing the general debian growth rate [0]? Is the
> slight downtick over the last few months due to the default desktop,
> or some other change that
On Fri, Aug 8, 2014 at 12:41 AM, Joey Hess wrote:
>> Hardware: GNOME 3.12 will be one of the few desktop environments to support
>> HiDPI displays, now very common on some laptop models. Lack of support for
>> HiDPI means non-technical users will get an unreadable desktop by default,
>> and
>> no
On Tue, Aug 5, 2014 at 11:45 AM, Wookey wrote:
> I really don't see sufficient reasons why we shouldn't at least put it
> experimental so that maintainers can easily test this stuff.
The problem is an undermanned ftpmaster team [0], so help there is
probably appreciated and the obvious way to brin
On Tue, Jul 15, 2014 at 3:50 PM, Scott Kitterman wrote:
> It would be nice, however, to have a way to specify the alternate behavior in
> a consistent reliable way (meaning something I can put in the package when I
> add source/format).
Archive consistency is far more important than individual mai
On Wed, Feb 26, 2014 at 12:36 PM, Peter Samuelson wrote:
>
> [micah]
>> it feels like a bit too aggressive pressure for my tastes. I've seen
>> a lot of developers of packages who have found out their package will
>> be removed from testing, but don't have the time to resolve the
>> situation befor
On Mon, Jan 6, 2014 at 7:59 AM, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Delegation for the Release Team"):
>> On 06/01/14 at 11:56 +, Neil McGovern wrote:
>> > Explicitly again: Please see the last 7 years worth of bits mails, where
>> > the release team have lowered this without advan
On Tue, Dec 31, 2013 at 4:34 AM, Niels Thykier wrote:
>> I wonder, how is the release team measuring this? For the other ports that
>> you mention, you've pointed to concrete technical problems that are in line
>> with the previously-documented release qualification guidelines. kfreebsd,
>> OTOH,
On Fri, Dec 27, 2013 at 2:23 AM, Charles Plessy wrote:
> I would welcome clearer rules to decide what is strictly required to be built
> from source. In particular, I would welcome something like "The maintainer
> decides, and can be overruled by the Technical Comittee if needed". What
> follows
On Sun, Dec 1, 2013 at 12:53 PM, Stephen Gran wrote:
> Can you explain why you think it would be a good idea to remove the
> power to decide their own goals from a team, and why you think it would
> be good for Debian to have one team drive another team's goals? This is
> so different to how we us
control: affects -1 src:poppler
On Fri, Nov 22, 2013 at 3:56 AM, Josselin Mouette wrote:
> I fully agree with Adrian that your “fix” is absolutely incorrect.
Thanks for the feedback. I've canceled the nmu.
> It will temporarily make xpdf work again, and break many other packages
> that have bee
On Sun, Sep 1, 2013 at 6:04 AM, Paul Wise wrote:
> On Sat, Aug 31, 2013 at 5:57 PM, Michael Gilbert wrote:
>
>> I've been meaning to add more informative info to the security-tracker
>> about end-of-lifed packages. Right now you can see that info in the
>> raw track
On Tue, Aug 27, 2013 at 9:58 AM, Simon McVittie wrote:
> On 27/08/13 14:32, Pau Garcia i Quiles wrote:
>> What do you do with the 1 year of support Debian currently gives to
>> oldstable? It's also 1 year you stopped using that version, so no
>> technical challenge either.
>
> There does need to be
On Tue, Aug 27, 2013 at 4:50 PM, Pau Garcia i Quiles wrote:
> On Tue, Aug 27, 2013 at 7:18 PM, Russ Allbery wrote:
>
>> > IMHO the Security Team should not act as fixers themselves but more as
>> > proxies, passing information about a security issue to the maintainer of
>> > the package.
>>
>> And
On Mon, Aug 19, 2013 at 5:12 PM, Vincent Bernat wrote:
> ❦ 19 août 2013 22:19 CEST, Clint Byrum
>
>>> Many people seem to justify a switch to Ubuntu LTS with the argument of
>>> 5-year security support. This support only applies for packages in
>>> main. A common example is nginx which is in unive
On Sat, May 25, 2013 at 11:52 AM, Ben Hutchings wrote:
> On Sat, 2013-05-25 at 10:41 +0200, Ondřej Surý wrote:
>> > examples would be useful
>>
>>
>> I have no big problem pointing fingers on d-d.
>>
>>
>> Example 1: Dan Jacobson
>
> Often writes poor bug reports, but is not abusive.
>
> [...]
>>
On Tue, May 21, 2013 at 4:19 AM, Helmut Grohne wrote:
> On Tue, May 21, 2013 at 01:21:41AM +0200, Andreas Beckmann wrote:
>> That might be possible with DPAs and if upload management is changed
>> generally to get less "broken" packages into unstable. E.g.
>
> I think that most of the ideas you pre
On Thu, May 16, 2013 at 5:52 AM, Neil McGovern wrote:
> On Thu, May 16, 2013 at 12:29:11AM +0200, Kurt Roeckx wrote:
>> Some upstreams have a testing branch of there software and a
>> release branch. It's sometimes useful to have people test the
>> version in from the testing branch, and having it
On Sun, May 12, 2013 at 4:42 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Or the project could end up in a perpetual freeze. Every time the
>> floodgates are opened, another 1,000 bugs could get reported due to all
>> of the new transitions, and another freeze wi
On Sun, May 12, 2013 at 4:00 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:
>
>>> Right. Which is why we should immediately (for definitions of
>>> immediately that involve the release team taking a much-d
On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> I disagree that there is something fundamentally wrong with how
>> development is done. The primary problems with this cycle were that
>> there were something like 400 or 500 extra rc
On Thu, May 9, 2013 at 3:49 PM, Lars Wirzenius wrote:
> The wheezy freeze has been much too long. At ten months, it's four
> months longer than what we've gotten used to in several previous
> releases. Had we managed to keep the freeze at six months, it would
> still have been too long. I believe t
On Mon, May 6, 2013 at 8:49 AM, Andreas Beckmann wrote:
> Hi,
>
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
>
> * multiarch compatible binNMUs
> * disca
On Sat, May 4, 2013 at 12:14 PM, Andrey Rahmatullin wrote:
> On Sat, May 04, 2013 at 12:05:06PM -0400, Michael Gilbert wrote:
>> Again, as Thijs argued somewhat eloquently already earlier in this
>> thread, computational time is not the scarce resource to worry about;
>> hum
On Sat, May 4, 2013 at 11:58 AM, Andrey Rahmatullin wrote:
> On Sat, May 04, 2013 at 11:53:04AM -0400, Michael Gilbert wrote:
>> >> We've always treated "FTBFS if built twice in a row" bugs as important:
>> >> http://bugs.debian.org/cgi-bin/pkgreport.c
On Sat, May 4, 2013 at 11:48 AM, Michael Gilbert wrote:
> On Sat, May 4, 2013 at 6:09 AM, Jakub Wilk wrote:
>> We've always treated "FTBFS if built twice in a row" bugs as important:
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;t
On Sat, May 4, 2013 at 6:09 AM, Jakub Wilk wrote:
> We've always treated "FTBFS if built twice in a row" bugs as important:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=qa-doublebuild
The real question is whether or not there is a consensus within the
project
On Fri, May 3, 2013 at 9:25 AM, Thijs Kinkhorst wrote:
> On Fri, May 3, 2013 15:09, Wouter Verhelst wrote:
>>> > No, it's not. Source only uploads were banned many years ago, mainly
>>> due
>>> > to problems with maintainers not even build testing their packages.
>
>> They do. They just ignore the
On Fri, Apr 5, 2013 at 7:45 PM, carlos wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Thanks for your time and job!
> I've trying to use Chromiun latest trunk but its requires libc-bin > 2.15,
> even I use Debian Testing I do not have this package.
> Is thought to have libc 2.17 o
On Sun, Mar 31, 2013 at 11:56 AM, Wookey wrote:
> +++ Benjamin Drung [2013-03-30 22:49 +0100]:
>> Hi,
>>
>> devscripts ships a bunch of scripts to make the life of a Debian Package
>> maintainer easier. Not every script in there is Debian packaging
>> specific. Some of them are used on other non-De
On Wed, Mar 6, 2013 at 11:56 AM, Michael Gilbert wrote:
> On Wed, Mar 6, 2013 at 7:46 AM, Holger Levsen wrote:
>>> IMO it's better to leave it in dput-ng and not moving it into
>>> devscripts.
>>
>> why? I don't want dput-ng (yet?) but I'd like t
On Wed, Mar 6, 2013 at 7:46 AM, Holger Levsen wrote:
>> IMO it's better to leave it in dput-ng and not moving it into
>> devscripts.
>
> why? I don't want dput-ng (yet?) but I'd like to have a dm command in
> devscripts. Whats your reasoning not to?
It's up to people interested dcut(classic) to su
On Fri, Mar 1, 2013 at 8:36 PM, Russ Allbery wrote:
>> They may seem intimidating, but they're usually fairly straightforward
>> with a little research.
>
> While I certainly don't want to discourage people from working on
> security-related bugs, note that security-related bugs don't block the
> r
> I wonder in how far I could do my share in the bug count reduction
> business. Perhaps in helping finding bugs belonging into such
> categories to attract the right people to the right bug and help
> reducing the time for people to detect a reasonable target for
> squashing?
There are always se
On Thu, Jan 24, 2013 at 12:39 AM, martin f krafft wrote:
> Hey folks,
>
> For a while now, the backports archive sets "ButAutomaticUpdates:
> yes" in its Release file, causing packages in the archive to be
> pinned with priority 100, rather than 1 (which was previously the
> case).
>
> The effect o
On Sat, Jan 5, 2013 at 12:36 AM, Thomas Goirand wrote:
> On 01/05/2013 01:28 AM, alberto fuentes wrote:
>> The few people on the list seems happy with it. If this is working
>> well, it needs a little more love on debian.org and a 'testing-cut'
>> link in the repos pointing to latest cut, so it ca
On Thu, Jan 10, 2013 at 3:21 AM, Andreas Beckmann wrote:
> Excluding shipped files from .md5sums looks seriously wrong for files
> in /usr and at least questionable in /var/lib.
What is so "serious" about that? Please no more rc mbf's.
Thanks,
Mike
--
To UNSUBSCRIBE, email to debian-devel-req
On Thu, Nov 1, 2012 at 6:59 PM, Bart Martens wrote:
> On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote:
>> Maybe an example will help get us on the same page. Russ seems to
>> have the impression that my proposal is somehow a license to push
>> unwanted ch
On Thu, Nov 1, 2012 at 5:00 PM, Stefano Zacchiroli wrote:
> On Thu, Nov 01, 2012 at 04:30:51PM -0400, Michael Gilbert wrote:
>> > You're still making the maintainer take explicit action to stop
>> > something that he already said they didn't want to happen.
>&g
On Thu, Nov 1, 2012 at 3:29 PM, Russ Allbery wrote:
>> That's where nmus help. Someone that does care and does have the time
>> can go ahead and get the features interesting them (and likely many
>> other users) to work.
>
> That's only true if you're happy with all of the changes being reverted
On Thu, Nov 1, 2012 at 3:16 PM, Tollef Fog Heen wrote:
>> > The new upstream release did not include any particularly compelling
>> > changes for wheezy, which is why I did not update to the newer
>> > upstream version.
>>
>> It may not have include changes interesting to you, but there was
>> cert
On Thu, Nov 1, 2012 at 4:48 AM, Bart Martens wrote:
>> wine: http://bugs.debian.org/585409 (new upstream pushed via nmu)
>
> This is a good example where talking helped to gather all views on all aspects
> from all involved people. My impression is that finally the maintainer
> allowed
> new co-m
On Thu, Nov 1, 2012 at 5:51 AM, Tollef Fog Heen wrote:
> ]] Michael Gilbert
>
>> mlocate: http://bugs.debian.org/669368 (new upstream could have been
>> pushed via nmu before the freeze, but it was prepared too late)
>>
>
> The suggested NMU that does random chang
On Wed, Oct 31, 2012 at 2:34 PM, Bart Martens wrote:
> On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote:
>> How to solve the following problem: Assume a package with wishlist bugs
>> filed lagging behind upstream and the maintainer refuses to package any
>> newer upstream, not even in
On Wed, Oct 31, 2012 at 3:05 AM, Andreas Tille wrote:
>> Unless we're having some heavyweight process with multiple pings
>> etc. (which we IMO shouldn't) the way the maintainer might first
>> discover that someone feels the package needs to be orphaned is by the
>> ITO bug. The maintainer needs
On Tue, Oct 30, 2012 at 12:47 PM, Jerome BENOIT wrote:
>> Is this not something best managed on a case-by-case basis?
>
> my experience as potential sponsoree for such a package answers me no
> because
> it is hard to get a sponsor.
If it fixes *only* rc bugs, then send a bug to sponsorship-reques
On Sun, Oct 28, 2012 at 12:07 PM, Russ Allbery wrote:
>>> If, as Bart has found, such mistakes are quite rare, then why worry so
>>> much? We don't need new formal processes for rarely occurring social
>>> problems. We need more people willing to help those that make social
>>> mistakes to learn
On Sun, Oct 28, 2012 at 12:25 PM, Wouter Verhelst wrote:
> If not, why are you claiming to replace their code? It's fine to be
> writing "something else" to replace older code; but it's fairly rude to
> be claiming that whatever you're writing is the "next generation" of
> that older code
Any rewr
On Sat, Oct 27, 2012 at 8:51 PM, Charles Plessy wrote:
>> maybe we could simply allow anyone, including non-DDs, to submit O-bugs for
>> packages which seem abandoned by the maintainer, and to submit ITA-bugs for
>> packages he/she wishes to salvage.
>
> I think that this misses one of the reasons
On Sat, Oct 27, 2012 at 10:19 AM, Bart Martens wrote:
> So maybe we could simply allow
> anyone, including non-DDs, to submit O-bugs for packages which seem abandoned
> by the maintainer, and to submit ITA-bugs for packages he/she wishes to
> salvage. Sounds revolutionary, but in reality this is m
On Fri, Oct 26, 2012 at 8:19 PM, Steve Langasek wrote:
> On Fri, Oct 26, 2012 at 07:33:27PM -0400, Michael Gilbert wrote:
>
>> We already orphan packages without the maintainer's consent, and it's
>> already called "orphaning".
>
>> Salvaging is sti
On Fri, Oct 26, 2012 at 6:06 PM, Steve Langasek wrote:
> On Fri, Oct 26, 2012 at 03:10:30PM -0400, Michael Gilbert wrote:
>> On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote:
>> > On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
>> >> I t
On Fri, Oct 26, 2012 at 7:46 AM, Arno Töll wrote:
> *) we have consensus that we are in need of such a rule set - which ever
> it may be
>
> *) we have three orthogonally different ideas:
>a) Bart's approach which was reformulated and proposed by Lucas in
> this thread [1]
>b) Mine - which
On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote:
> On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
>> I think this is where language is important. In my opinion, the term
>> "adoption" will continue to mean taking on full responsibility fo
On Thu, Oct 25, 2012 at 9:14 PM, Russ Allbery wrote:
>> I respect your opinion, so I'm just curious which part do you believe
>> won't work in common cases? It's just applying existing NMU rules with
>> a little more liberalism to increase activity in under-maintained
>> packages, so I personally
On Thu, Oct 25, 2012 at 8:18 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Thu, Oct 25, 2012 at 7:52 PM, Russ Allbery wrote:
>
>>> I certainly have no objection to people doing this, but I'm not sure
>>> that's really what we're discussing he
On Thu, Oct 25, 2012 at 7:19 PM, Russ Allbery wrote:
>> As I've said many times now, the liberal NMU would not be a license for
>> packaging style changes. In fact, no NMU is allowed to make those
>> changes (the fact that people are doing it is apparently a social issue,
>> and solutions to those
On Thu, Oct 25, 2012 at 6:50 PM, Arno Töll wrote:
> On 25.10.2012 21:09, Michael Gilbert wrote:
>> 2. Salvager uploads liberal (10-day delayed) nmus as needed to bring
>> the package into a better maintained state.
>
> Please let's not go that road. Mixi
On Thu, Oct 25, 2012 at 6:15 PM, Michael Gilbert wrote:
>> When fixing non important bugs, or improving the package quality, like
>> switching to format 3 source, arranging the rules file, and so on, I fear
>> it will be very difficult to find a sponsor for these nmus.
>
&g
On Thu, Oct 25, 2012 at 6:05 PM, Jean-Michel Vourgère wrote:
> On Thursday 25 October 2012 19:09:55 Michael Gilbert wrote:
>> (...)
>> I would prefer to see even more autonomy for the salvager and less
>> bugging of various lists (ITPs on -devel are already distracting
>
On Thu, Oct 25, 2012 at 9:50 AM, Ian Jackson
wrote:
> Scott Kitterman writes ("Re: [SUMMARY/PROPOSAL] Orphaning another
> maintainer's packages"):
>> Why not start with a "without objection" standard and see how it
>> works?
>
> I absolutely agree with this.
>
> If we adopt a "without objection"
On Thu, Oct 18, 2012 at 9:19 PM, Christoph Anton Mitterer wrote:
> 2) downgrade attacks
> These have the same idea as blocking attacks (prevent the user to get
> updates) but are a bit smarter.
> You don't simply block any update requests, but rather you sent the user
> old repository data. These a
On Wed, Oct 17, 2012 at 2:56 AM, Joerg Jaspert wrote:
> On 13001 March 1977, Michael Gilbert wrote:
>
>> So, are we ready to do this?
>
> No.
> Its for after wheezy, definitely.
> Also, there are some open issues to be solved for this to happen.
> The most important is b
On Wed, Oct 17, 2012 at 10:22 PM, Matthew Grant wrote:
> On Wed, Oct 17, 2012 at 1:57 PM, Michael Gilbert
>> No. We're in the freeze now. Fixes need to be backported.
>
>
> If backporting a fix is not possible with the certainty of no introduced
> bugs, we have n
On Wed, Oct 17, 2012 at 5:23 PM, Michael Gilbert wrote:
> That is true: if there is a build path sanitization issue, then if the
> user chooses to rebuild the package they will get their own rogue
> paths. So, yes, we should always fix those issues when they're found,
> but at
On Wed, Oct 17, 2012 at 4:55 PM, Bernhard R. Link wrote:
> * Michael Gilbert [121017 22:19]:
>> Anyway, reading again, I not sure that your reply actually considers
>> build path sanitization problems, which is what my statement was
>> about.
>
> I'm stating that
On Wed, Oct 17, 2012 at 4:07 PM, Bernhard R. Link wrote:
> * Michael Gilbert [121016 04:59]:
>> Anyway, all of these build system path sanitization issues can be
>> eliminated by using the buildds for all architectures, since paths
>> will start with at least /build tha
I know this subject has been discussed on and off in the past, but
there's new evidence that it's simply the right thing to do.
Due to changes in upstream's build system, isc-dhcp recently started
including build system paths in dhclient's search path. This got a
security identifier, and we've fi
On Sun, Oct 14, 2012 at 9:08 PM, Christoph Anton Mitterer wrote:
>> If so, please submit
>> bugs, and we will look at fixing them. Otherwise, speculation gets us
>> nowhere and actually wastes time.
> Well I had once a discussion (around March this year) here about
> blockin/downgrade attacks... w
On Fri, Oct 12, 2012 at 4:45 PM, Christoph Anton Mitterer wrote:
> On Fri, 2012-10-12 at 16:37 -0400, Michael Gilbert wrote:
>> Which is impossible, or at least man-powerwise insurmountable. There
>> are something like 500 million lines of code in a Debian release.
> I wasn&#x
On Fri, Oct 12, 2012 at 4:31 PM, Christoph Anton Mitterer wrote:
> But it's a general security paradigm, that one shouldn't just focus on
> the attack vectors one can think of... but rather trying to secure
> "everything" ;)
Which is impossible, or at least man-powerwise insurmountable. There
are
On Wed, Oct 10, 2012 at 6:04 PM, Lucas Nussbaum wrote:
> So, reading this thread (which was surprisingly quiet, given the topic),
> it seems that everybody agrees that such a procedure would be a good
> thing (nobody had fundamental concerns). But now we have two proposed
> procedures:
> - one wh
On Mon, Oct 8, 2012 at 6:33 AM, Thomas Goirand wrote:
> On 10/08/2012 01:21 AM, Julien Cristau wrote:
>>> Would it be appropriate to file RC bugs against all the packages
>>> shipping anything in /var/run, /var/lock or /run?
>>>
>> No, there's nothing wrong with that.
>>
>> Cheers,
>> Julien
>
> Li
1 - 100 of 233 matches
Mail list logo
