Raphael Geissert writes:
> Russ Allbery wrote:
>> What I'm saying is that *all* of that data that you moved from one
>> place to another should be in Lintian::Data. I want to get away from
>> having these big static hashes in the check scripts where we can and
>> move that data into Lintian::Dat
Russ Allbery wrote:
[...]
>
> I applied this patch because it's an improvement over what we had
> previously, but I think you misread my message.
Indeed :-/
> What I'm saying is that
> *all* of that data that you moved from one place to another should be in
> Lintian::Data. I want to get away
Raphael Geissert writes:
> Implemented, see attached mbox.
This all looks good to me except this one:
> diff --git a/collection/strings b/collection/strings
> index b649035..94bac2d 100755
> --- a/collection/strings
> +++ b/collection/strings
> @@ -34,7 +34,9 @@ for bin in $(grep ELF file-info
Raphael Geissert writes:
> Russ Allbery wrote:
>> Raphael Geissert writes:
>>> None of these require my previous changes to be applied, but would be
>>> great if the others could be applied as well.
>> I applied the first patch. For the move of common_data, I agree that
>> this is an improvemen
Russ Allbery wrote:
> Raphael Geissert writes:
>
>> None of these require my previous changes to be applied, but would be
>> great if the others could be applied as well.
>
> I applied the first patch. For the move of common_data, I agree that this
> is an improvement over the current state, bu
Russ Allbery wrote:
> Raphael Geissert writes:
[...]
>
>> Do you handle that one?
>
> Not at the moment. I have lots of other things I want to work on first.
>
Implemented, see attached mbox.
[...]
>
> The proof-of-concept looks like a reasonable approach. I hadn't thought
> of using Data::
Raphael Geissert writes:
> None of these require my previous changes to be applied, but would be
> great if the others could be applied as well.
I applied the first patch. For the move of common_data, I agree that this
is an improvement over the current state, but except for %known_arches,
that
Raphael Geissert writes:
> Russ Allbery wrote:
>> Raphael Geissert writes:
>>> At least the collection scripts could be run in parallel. All the
>>> collection scripts with the same Order should run in parallel just
>>> fine, and once the dependencies are done or all the scripts of the
>>> same O
Raphael Geissert writes:
> None of these require my previous changes to be applied, but would be
> great if the others could be applied as well.
I still have all these queued up, but I processed open bugs (particularly
false positives and the like) and fixes for known bugs first, and
realistical
Hi all,
None of these require my previous changes to be applied, but would be great
if the others could be applied as well.
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
lintian_profil3.mbox
Description: application/mbox
lintian_reorg.mbox
Description: appl
Some other optimisations and a new check/bug fix, found by somebody in
#debian-mentors
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
lintian-copyright_license_typo.mbox
Description: application/mbox
lintian-data_optim.mbox
Description: application/mbox
Russ Allbery wrote:
> Raphael Geissert writes:
>
>> At least the collection scripts could be run in parallel. All the
>> collection scripts with the same Order should run in parallel just fine,
>> and once the dependencies are done or all the scripts of the same Order
>> are done the next ones co
Raphael Geissert writes:
> Russ Allbery wrote:
>> I don't want to dismiss using threads, since I know that making disk
>> access asynchronous can help quite a bit, but I'm very nervous about
>> introducing the complexity of thread management into the Lintian code.
>> Threads tend to cause a lot o
Russ Allbery wrote:
[...]
>
> I don't want to dismiss using threads, since I know that making disk
> access asynchronous can help quite a bit, but I'm very nervous about
> introducing the complexity of thread management into the Lintian code.
> Threads tend to cause a lot of obscure and difficult-t
Raphael Geissert writes:
> Attached is the first set.
Will review in a bit. Thank you!
> We could speed up lintian a bit more by:
> * Running the collection scripts in multiple threads.
> * Use threads or Async to run some of the Lintian::Collection methods if we
> know we are going to use the
Raphael Geissert writes:
> Russ Allbery wrote:
>> More detail would be good. The only things that level 1 unpack of
>> binary packages generates are the control directory and index, the file
>> indices, and the breakdown of the package control information, plus a
>> symlink.
> The fields don't
Raphael Geissert wrote:
[...]
> I just started to optimise the code, reduce number of calls, etc based on
> the profiling data (by moving some code I reduced over 2k function calls).
> Will send some patches tomorrow.
>
Attached is the first set.
We could speed up lintian a bit more by:
* Running
Russ Allbery wrote:
> Raphael Geissert writes:
>> Russ Allbery wrote:
[...]
>> I remember seeing the other day some unneeded files being generated at
>> unpack level 1 of binary packages.
>
> More detail would be good. The only things that level 1 unpack of binary
> packages generates are the co
Raphael Geissert writes:
> Russ Allbery wrote:
>> Need to be rewritten to not use Dpkg::Version, which is not available
>> in stable. It looks good once that's done. (If past experience is a
>> guide, it will take some time before gluck is updated to lenny even
>> once lenny is released.)
> Di
Russ Allbery wrote:
> Raphael Geissert writes:
>
>> Attached are two mboxs, one adds a some more words to Spelling.pm;
>
> Applied.
Thanks
>
>> the other mbox contains the necessary changes to generate an index of
>> the source package, and file-index.
>
> Need to be rewritten to not use Dpk
Raphael Geissert writes:
> Attached are two mboxs, one adds a some more words to Spelling.pm;
Applied.
> the other mbox contains the necessary changes to generate an index of
> the source package, and file-index.
Need to be rewritten to not use Dpkg::Version, which is not available in
stable.
Hi all,
Attached are two mboxs, one adds a some more words to Spelling.pm; the other
mbox contains the necessary changes to generate an index of the source
package, and file-index.
The other day I was thinking that it should probably be better if the
indexes and some other info being generated by
22 matches
Mail list logo
