[Wikitech-l] Re: Adding Docker images to the registry via Gitlab

[Ahmon Dancy]

Sebastian, I created the Speechoid group per your request
https://gitlab.wikimedia.org/groups/repos/mediawiki/services/speechoid and
made you the owner.

On Thu, Mar 7, 2024 at 4:59 AM Sebastian Berlin <
sebastian.ber...@wikimedia.se> wrote:

> Thank you to the kind stranger who approved my request on Gitlab
>
> Now I have a followup question: how to add a subgroup under
> repos/mediawiki/services to match what is on Gerrit? It looks like I can't
> create one of those. I found a request form to add subgroup
> , but
> that one is explicitly for "top-level project group[s] under /repos".
>
> What I'd like to have is a subgroup under repos/mediawiki/services called
> "Speechoid" (changed from "wikispeech" in Gerrit to better describe what
> the service is).
>
> *Sebastian Berlin*
> Utvecklare/*Developer*
> Wikimedia Sverige (WMSE)
>
> E-post/*E-Mail*: sebastian.ber...@wikimedia.se
> Telefon/*Phone*: (+46) 0707 - 92 03 84
>
>
> On Thu, 7 Mar 2024 at 08:55, Sebastian Berlin <
> sebastian.ber...@wikimedia.se> wrote:
>
>> I'm trying to use the new workflow for uploading Docker images to the
>> registry. Following the link under wikitech:Docker-registry#Downloading
>> images
>> 
>> I ended up on mw:GitLab/Workflows/Deploying services to production
>> 
>> as the recommended way to do it.
>>
>> As far as I can tell the service repos should live under
>> repos/mediawiki/services/ in Gitlab and you need to have access to the
>> group to import repos there. I clicked on "Request access" in the menu for
>> that group, but I don't think anything has happened since then. Is there
>> anything else I need to do to be granted access?
>>
>> For context, the service I want to add Docker image for is part of
>> Speechoid, a service bundle(?) for Wikispeech
>> . Currently we have
>> a few other services that have their code on Gerrit
>> .
>>
>> *Sebastian Berlin*
>> Utvecklare/*Developer*
>> Wikimedia Sverige (WMSE)
>>
>> E-post/*E-Mail*: sebastian.ber...@wikimedia.se
>> Telefon/*Phone*: (+46) 0707 - 92 03 84
>>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: [Train] 1.41.0-wmf.18 status update: blocked at group1 on T342282

[Ahmon Dancy]

The train is now unblocked. T342282 has been removed as a train blocker.
Thanks to everyone who jumped in to verify!

On Thu, Jul 20, 2023 at 11:11 AM Ahmon Dancy  wrote:

> The 1.41.0-wmf.18 version of MediaWiki is blocked[0].
>
> The new version is currently deployed to group1[1], but can proceed no
> further until the issue is resolved.
>
> * T342282 - "View 1 notice" not working
> - https://phabricator.wikimedia.org/T342282
>
> Once the issue is confirmed and resolved the train can resume.
>
> Thank you for any help resolving this!
>
> -- Your humble train operator
>
> [0]. https://phabricator.wikimedia.org/T340246
> [1]. https://versions.toolforge.org/
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] [Train] 1.41.0-wmf.18 status update: blocked at group1 on T342282

[Ahmon Dancy]

The 1.41.0-wmf.18 version of MediaWiki is blocked[0].

The new version is currently deployed to group1[1], but can proceed no
further until the issue is resolved.

* T342282 - "View 1 notice" not working
- https://phabricator.wikimedia.org/T342282

Once the issue is confirmed and resolved the train can resume.

Thank you for any help resolving this!

-- Your humble train operator

[0]. https://phabricator.wikimedia.org/T340246
[1]. https://versions.toolforge.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Automatic import of users to /repos/mediawiki on GitLab

[Ahmon Dancy]

Today (Monday June 5th, 2023) at 15:00 UTC (8am US/Pacific) we ran the
account import operation that was announced a few days ago.  The operation
completed successfully.

You may have received an email from GitLab telling you that SSH keys were
added to your account.  These are SSH keys that are associated with your
Wikitech account that have been copied into GitLab.

There have been reports of users having difficulty setting up two factor
authentication (2FA) on their accounts.  The problem and workaround is
described in an existing GitLab issue:
https://gitlab.com/gitlab-org/gitlab/-/issues/344527.

-- Release Engineering

On Fri, Jun 2, 2023 at 3:22 PM Ahmon Dancy  wrote:

> Hey all,
>
> On Monday June 5th, 2023 at 15:00 UTC (8am US/Pacific) we (the Release
> Engineering Team) will run scripts[0] to add a bunch of users to the
> /repos/mediawiki group[1] on GitLab. You may see mail from GitLab as a
> result.
>
> We're adding accounts from the wmf and ops LDAP groups, to be synchronized
> regularly.  We'll also be doing a one-time import of the mediawiki group
> defined in Gerrit. Users will initially be added with a GitLab role of
> "Developer". If a user has not yet logged into GitLab with their developer
> account, this process will first create a GitLab account for them.
>
> While there's a lot to be done yet, this is one step in migrating
> MediaWiki development to GitLab. You can track our progress on this at
> T335921[2], and review a draft of the proposed namespace layout and
> permissions policy on mw.org[3].
>
> Thanks!
>
> -- Release Engineering
>
> [0].
> https://gitlab.wikimedia.org/repos/releng/gitlab-settings/-/tree/main/group-management
> [1]. https://gitlab.wikimedia.org/repos/mediawiki/
> [2]. https://phabricator.wikimedia.org/T335921
> [3]. https://www.mediawiki.org/wiki/GitLab/Policy#MediaWiki_namespace
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Automatic import of users to /repos/mediawiki on GitLab

[Ahmon Dancy]

Hey all,

On Monday June 5th, 2023 at 15:00 UTC (8am US/Pacific) we (the Release
Engineering Team) will run scripts[0] to add a bunch of users to the
/repos/mediawiki group[1] on GitLab. You may see mail from GitLab as a
result.

We're adding accounts from the wmf and ops LDAP groups, to be synchronized
regularly.  We'll also be doing a one-time import of the mediawiki group
defined in Gerrit. Users will initially be added with a GitLab role of
"Developer". If a user has not yet logged into GitLab with their developer
account, this process will first create a GitLab account for them.

While there's a lot to be done yet, this is one step in migrating MediaWiki
development to GitLab. You can track our progress on this at T335921[2],
and review a draft of the proposed namespace layout and permissions policy
on mw.org[3].

Thanks!

-- Release Engineering

[0].
https://gitlab.wikimedia.org/repos/releng/gitlab-settings/-/tree/main/group-management
[1]. https://gitlab.wikimedia.org/repos/mediawiki/
[2]. https://phabricator.wikimedia.org/T335921
[3]. https://www.mediawiki.org/wiki/GitLab/Policy#MediaWiki_namespace
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Betacluster-alerts] Re: beta-code-update-eqiad - Build # 441997 - Failure!

[Ahmon Dancy]

This happened because I updated scap while the job was running.   It should
recover in 10 minutes.

On Tue, May 2, 2023 at 9:55 AM Release Engineering <
jenkins-...@wikimedia.org> wrote:

> beta-code-update-eqiad - Build # 441997 - Failure: Check console output at
> https://integration.wikimedia.org/ci/job/beta-code-update-eqiad/441997/
> to view the results.___
> Betacluster-alerts mailing list -- betacluster-alerts@lists.wikimedia.org
> To unsubscribe send an email to
> betacluster-alerts-le...@lists.wikimedia.org
>
___
Betacluster-alerts mailing list -- betacluster-alerts@lists.wikimedia.org
To unsubscribe send an email to betacluster-alerts-le...@lists.wikimedia.org

[Wikitech-l] Summary of 1.40.0-wmf.12 train deployment

[Ahmon Dancy]

This email is a summary of the Wikimedia production deployment of
1.40.0-wmf.12

   - Conductor: Ahmon Dancy
   - Backup Conductor: Brennen Bearnes
   - Blocker Task: T320517 <https://phabricator.wikimedia.org/T320517>
   - Status: Rolled out to all wikis
   -
   -  By the Numbers

Sparklines comparing with the last 5 trains.

   - 565 Patches ▂▁▁█▇
   - 0 Rollbacks ▄▁▁█▁
   - 0 Days of delay ▁▁▁█▁
   - 4 Blockers █▁▂▅▇

殺 Trainbow Love 殺Thanks to folks who reported or resolved blockers:

   - Jon Robson
   - Bartosz Dziewoński
   - Subbu
   - Matthias Mullie
   - Taavi Väänänen
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Summary of 1.40.0-wmf.1 train deployment

[Ahmon Dancy]

This email is a summary of the Wikimedia production deployment of
1.40.0-wmf.1

   - Conductor: Ahmon Dancy
   - Backup Conductor: Jeena Huneidi
   - Blocker Task: T314190 <https://phabricator.wikimedia.org/T314190>
   - Status: Deployed to all wikis

 Stats

Sparklines comparing with the last 5 trains.

   - 242 Patches ▁▃██▇
   - 2 Rollbacks █▃▁▃▆
   - 1 Days of delay ▁█▁██
   - 3 Blockers ▃█▁▁▃

 Traintastic Folks Thanks to folks who reported or resolved blockers:

   - C. Scott Ananian
   - Michael Große (WMDE)
   - Taavi Väänänen
   - Lucas Werkmeister (WMDE)
   - Amir Sarabadani
   - Jon Robson
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Summary of 1.39.0-wmf.23 train deployment

[Ahmon Dancy]

This email is a summary of the Wikimedia production deployment of
1.39.0-wmf.23

Conductor: Ahmon Dancy
Backup Conductor: Brennen Bearnes
Blocker Task: T308076
Status: Deployed to all wikis

 Numbers
Sparklines comparing with the last 5 trains.
322 Patches ▅█▃▁▄
1 Rollbacks ▁▁█▁▃
0 Days of delay ▄
2 Blockers ▁▁█▄▂

 Trainlicious Shoutouts 
Thanks to folks who reported or resolved blockers:
Amir Sarabadani
C. Scott Ananian
Subbu
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Summary of 1.39.0-wmf.13 train deployment

[Ahmon Dancy]

This email is a summary of the Wikimedia production deployment of
1.39.0-wmf.13

   - Conductor: Ahmon Dancy (That's my name, don't wear it out)
   - Backup Conductor: Jaime Nuche
   - Blocker Task: T305219 <https://phabricator.wikimedia.org/T305219>
   - Status: Rolled out to all wikis on May 26, 2022

 According to our calculations

Sparklines comparing the last 5 trains.

   - 299 Patches ▁▃▂█▆
   - 0 Rollbacks ▁▁█▁▁
   - 0 Days of delay ▁▁█▁▁
   - 4 Blockers ▁▁█▃▂

 Trainbow Love ✨Thanks to folks who reported or resolved blockers:

   - Bartosz Dziewoński
   - Zabe
   - Abijeet Patro
   - James D. Forrester
   - Jon Robson
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re:  Amir Sarabadani receives Web Perf Hero award!

[Ahmon Dancy]

Nice work Amir!

On Thu, May 26, 2022 at 7:22 AM Krinkle  wrote:

> I'm happy to share that the first Web Perf Hero award of 2022 goes to Amir
> Sarabadani!
>
> This award is in recognition of Amir's work (@Ladsgroup) over the past six
> months, in which he demonstrated deep expertise of the MediaWiki platform
> and significantly sped up the process of saving edits in MediaWiki. This
> improved both the potential of MediaWiki core, and as experienced
> concretely on WMF wikis, especially on Wikidata.org.
>
> Refer to the below medawiki.org page to read about what it took to *cut
> latencies by half*:
>
> https://www.mediawiki.org/wiki/Wikimedia_Performance_Team/Web_Perf_Hero_award#Amir_Sarabadani
>
> This award is given on a quarterly basis, and manifests as a Phabricator
> badge:
> https://phabricator.wikimedia.org/badges/view/17/
>
> -- Timo Tijhof, on behalf of WMF Performance Team.
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Summary of 1.39.0-wmf.7 train deployment

[Ahmon Dancy]

 This email is a summary of the Wikimedia production deployment of
1.39.0-wmf.7

   - Conductor: Ahmon Dancy (yours truly)
   - Backup Conductor: Jaime Nuche
   - Blocker Task: T305213 <https://phabricator.wikimedia.org/T305213>
   - Current Status <https://versions.toolforge.org>

 According to our calculations

Sparklines comparing with the last 5 trains.

   - 273 Patches ▁▁▅█▆
   - 0 Rollbacks ▁█▁█▁
   - 0 Days of delay ▄
   - 4 Blockers ▅█▁▂▃

 Traintastic Folks  Thanks to folks who reported or resolved blockers:

   - Samuel
   - Timo Tijhof
   - Zabe
   - Antoine "hashar" Musso
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Summary of 1.38.0-wmf.25 train deployment

[Ahmon Dancy]

This email is a summary of the Wikimedia production deployment of
1.38.0-wmf.25

   - Conductor: Ahmon Dancy
   - Backup Conductor: Brennen Bearnes
   - Blocker Task: T300201 <https://phabricator.wikimedia.org/T300201>
   - Current Status <https://versions.toolforge.org/>: Stable on all wikis.

 By the Numbers

Sparklines comparing with the last 5 trains.


   - 368 Patches ▃▅▁▄█
   - 1 Rollbacks █
   - 0 Days of delay ▄
   - 9 Blockers ▁▁▁▂█

殺 Traintastic Folks 

Thanks to folks who reported or resolved blockers:

   - Bryan Davis
   - Bartosz Dziewoński
   - Timo Tijhof
   - Zabe
   - Dom Walden
   - Ammarpad
   - Xiplus
   - Kosta Harlan
   - Subramanya Sastry
   - Jon Robson
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Betacluster-alerts] Re: beta-mediawiki-config-update-eqiad - Build # 221 - Failure!

[Ahmon Dancy]

Sorry about these noisy alerts.  We should have them fixed up by tomorrow.


On Thu, Mar 3, 2022 at 9:47 AM Release Engineering <
jenkins-...@wikimedia.org> wrote:

> beta-mediawiki-config-update-eqiad - Build # 221 - Failure: Check console
> output at
> https://integration.wikimedia.org/ci/job/beta-mediawiki-config-update-eqiad/221/
> to view the results.___
> Betacluster-alerts mailing list -- betacluster-alerts@lists.wikimedia.org
> To unsubscribe send an email to
> betacluster-alerts-le...@lists.wikimedia.org
>
___
Betacluster-alerts mailing list -- betacluster-alerts@lists.wikimedia.org
To unsubscribe send an email to betacluster-alerts-le...@lists.wikimedia.org

[Wikitech-l] Summary of 1.38.0-wmf.20 train deployment

[Ahmon Dancy]

This email is a summary of last week's Wikimedia production deployment of
1.38.0-wmf.20

   - Conductor: Ahmon Dancy
   - Backup Conductor: Brennen Bearnes
   - Blocker Task: T293961 <https://phabricator.wikimedia.org/T293961>

 Stats

Sparklines comparing with the last 5 trains.

   - 346 Patches ▁▇▇▇█
   - 0 Rollbacks ▁█▁▂▁
   - 0 Days of delay ▂█▁▂▁
   - 2 Blockers ▂▃▆█▁

 Trainbow Love ✨Thanks to folks who reported or resolved blockers:

   - Raimond Spekking
   - Samuel
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Betacluster-alerts] Re: beta-code-update-eqiad - Build # 376129 - Failure!

[Ahmon Dancy]

This is me working on stuff.

On Thu, Jan 13, 2022 at 8:46 AM Release Engineering <
jenkins-...@wikimedia.org> wrote:

> beta-code-update-eqiad - Build # 376129 - Failure: Check console output at
> https://integration.wikimedia.org/ci/job/beta-code-update-eqiad/376129/
> to view the results.___
> Betacluster-alerts mailing list -- betacluster-alerts@lists.wikimedia.org
> To unsubscribe send an email to
> betacluster-alerts-le...@lists.wikimedia.org
>
___
Betacluster-alerts mailing list -- betacluster-alerts@lists.wikimedia.org
To unsubscribe send an email to betacluster-alerts-le...@lists.wikimedia.org

[Wikitech-l] Summary of 1.38.0-wmf.12 train deployment

[Ahmon Dancy]

   - 1.38.0-wmf.12 has been rolled out to all wikis.  There are a couple of
   low frequency errors that are being logged bug they are being worked on.



   - Conductor: Ahmon Dancy (yours truly)
   - Backup Conductor: Brennen Bearnes
   - Blocker Task: T293953 <https://phabricator.wikimedia.org/T293953>
   - Current Status <https://versions.toolforge.org/>

 By the Numbers

Sparklines comparing with the last 5 trains.

   - 231 Patches █▅▁▅▂
   - 1 Rollbacks ▁▃█▆▃
   - 0 Days of delay ▁▂▆█▁
   - 8 Blockers ▃▃▁█▇

✨ Trainbow Love Thanks to folks who reported or resolved blockers:

   - Amir Sarabadani (WMF)
   - Timo Tijhof
   - Taavi Väänänen
   - EBernhardson
   - Daniel Kinzler
   - Roan Kattouw
   - Jon Robson
   - Zabe
   - and many more!
   -
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l]  Summary of the 1.37.0-wmf.23 train deployment

[Ahmon Dancy]

Another week, another train.

Your train conductors: mmodell and hashar
Phabricator Task: T281164 
Deployment Status: Live on all wikis 

Notable things about this train:

   - Train happened during DC switchover week (codfw -> eqiad).
   - Italian wikipedia moved from group2 to group1, bringing the number of
   group1 wikis to 3. Thanks Jon Robson
   - 3 risky change notifications.  Thank you!

Many thanks to the following people who participated in this week's train.
We can't do it without you!

daniel
DannyS712
Zabe
Legoktm
Majavah
Joe
James F
Umherirrender
Etonkovidova
matmarex
Krinkle
Jdlrobson
AntiCompositeNumber
Daimona
urbanecm
Tgr
Mholloway
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Nomination for Majavah to get +2 rights in mediawiki/

[Ahmon Dancy]

Congrats! Well deserved.

On Fri, Aug 27, 2021 at 12:34 AM Kunal Mehta  wrote:

> With a unanimous consensus, I have granted Majavah +2 rights. Congrats!
>
> -- Legoktm
>
> ___
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Re: Gerrit upgrade August 3rd 16:00 UTC

[Ahmon Dancy]

Gerrit has been upgraded to version 3.3.5.  Please let Release Engineering
know if you have any problems.

Enjoy!

On Thu, Jul 29, 2021 at 2:23 PM Ahmon Dancy  wrote:

> Hello,
>
> We will upgrade our Gerrit to [version 3.3].  We have scheduled it on
> Tuesday, August 3rd at 16:00 UTC. We will first upgrade the [Gerrit
> replica] then the primary server. The service will thus be unavailable for
> a few minutes while we conduct the operation and restart the service.
>
> The July 19th upgrade took a bit longer than expected since we were trying
> our runbook for the first time. We have since improved our documentation
> and addressed a few configuration glitches we had.
>
> This upgrade comes with a new feature: "Attention Set". It replaces change
> *assignees* with a list of people that are expected to act on the change.
> It helps better differentiate changes you have already reviewed from the
> one you have to review or amend. The feature is nicely explained on
> upstream documentation page:
>
> http://gerrit-documentation.storage.googleapis.com/Documentation/3.3.1/user-attention-set.html
>
> Ahmon, Antoine, Brennen
> Release Engineering
>
> [version 3.3] https://www.gerritcodereview.com/3.3.html
> [Gerrit replica]
> https://wikitech.wikimedia.org/wiki/Gerrit-replica.wikimedia.org
> Upgrade task: https://phabricator.wikimedia.org/T262241
>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] Gerrit upgrade August 3rd 16:00 UTC

[Ahmon Dancy]

Hello,

We will upgrade our Gerrit to [version 3.3].  We have scheduled it on
Tuesday, August 3rd at 16:00 UTC. We will first upgrade the [Gerrit
replica] then the primary server. The service will thus be unavailable for
a few minutes while we conduct the operation and restart the service.

The July 19th upgrade took a bit longer than expected since we were trying
our runbook for the first time. We have since improved our documentation
and addressed a few configuration glitches we had.

This upgrade comes with a new feature: "Attention Set". It replaces change
*assignees* with a list of people that are expected to act on the change.
It helps better differentiate changes you have already reviewed from the
one you have to review or amend. The feature is nicely explained on
upstream documentation page:
http://gerrit-documentation.storage.googleapis.com/Documentation/3.3.1/user-attention-set.html

Ahmon, Antoine, Brennen
Release Engineering

[version 3.3] https://www.gerritcodereview.com/3.3.html
[Gerrit replica]
https://wikitech.wikimedia.org/wiki/Gerrit-replica.wikimedia.org
Upgrade task: https://phabricator.wikimedia.org/T262241
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/

[Wikitech-l] [Train] 1.37.0-wmf.5 status update (blocked at group0)

[Ahmon Dancy]

Hi all,

The 1.37.0-wmf.5[0] train is currently blocked at group0 by the
following issue:

* Wikimedia\Rdbms\DBQueryError: Error 1048: Column 'gt_page_id' cannot
 be null (db1138)Function: GeoData\Hooks::doLinksUpdateQuery: INSERT
 INTO `geo_tags`
(gt_page_id,gt_id,gt_lat,gt_lon,gt_globe,gt_primary,gt_dim,gt_type,gt_name,gt_country,gt_region)

 VALUES
(NULL,NULL,'45.8117','4.91944','earth',1,1000,'camera',NULL,NULL,NULL)

- https://phabricator.wikimedia.org/T282735

If this issue is resolved before the 19:00 UTC train deployment window,
the train will proceed as normal to group1.

As ever, you can follow train progress on Freenode's
#wikimedia-operations as well as on the blocker task[0].

Regards,

-- Your lovely train crew

[0]. 
[1]. <
https://wikitech.wikimedia.org/wiki/Deployments/Holding_the_train#Issues_that_hold_the_train>
___
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[Wikitech-l] [Train] 1.36.0-wmf.35 status update

[Ahmon Dancy]

The 1.36.0-wmf.35 train was briefly rolled out to group0 but was rolled
back due to an increase in logged errors attributed to T277362[0].   All
wikis are back to 1.36.0-wmf.34.

See the train blockers task[1] for all details about this week's train.

Thanks in advance for resolution of this issue!  Sincerely, your train
operator.

[0] https://phabricator.wikimedia.org/T277362
[1] https://phabricator.wikimedia.org/T274939
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Train] status 1.36.0-wmf.28

[Ahmon Dancy]

Train status 

1.36.0-wmf.28 is on group0.  There are some new log messages that need
investigation and cleanup:

T273120 ParserOptions.php PHP Notice: Undefined index: math
T273099: Undefined class constant 'BASE_CSS_CLASS' (A fix for this one
has been prepared and is expected to be deployed in about an hour).
T273101: Accessing WikiPage that cannot exist as a page: w:Help:Books/Book
creator text.

Thanks to everyone for your help in moving the train along!
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] [Train] status 1.36.0-wmf.28

[Ahmon Dancy]

The 1.36.0-wmf.28 version of MediaWiki is blocked[0]. The new version is
deployed to testwikis, but can proceed no further until these issues are
resolved:


** MediumSpecificBagOStuff.php Undefined offset errors:
https://phabricator.wikimedia.org/T273006
*
* CacheTime.php Undefined index Version
https://phabricator.wikimedia.org/T273007
(should be resolved during the next roll forward attempt)

* Failed assertion in TableFixups handler
https://phabricator.wikimedia.org/T265720
(may be downgraded from unbreak-now).

Once these issues are resolved train can resume. If these issues are
resolved on a Friday the train will resume Monday. Thank you for your help
resolving these issues! -- Your humble train toiler

[0]. 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: Finding depended-upon systems

[Ahmon Dancy]

Robert Goldman  wrote:

>> There was some discussion about this in connection with finding what
>> needed to be recompiled.  Is the latter even a query that ASDF can
>> answer?  In old ASDF we computed the plan first, and only after that did
>> we decide whether the operations needed performing.

I was the one who asked about that and this is what I ended up with:

(defun out-of-date-components (system  (other-systems t))
  "Returns a list of the components of SYSTEM (or its dependent systems,
   if OTHER-SYSTEMS is true (which is the default)) which are out-of-date."
  (let ((op (make-instance 'asdf/lisp-action:compile-op))
res)
(dolist (c (asdf:required-components system 
 :force nil :force-not nil 
:keep-component 'asdf:cl-source-file :keep-operation 'asdf:compile-op
 :other-systems other-systems))
  (when (eq (asdf/action:compute-action-stamp nil op c) t)
;; Operation timestamp is in the future.  This indicates that the 
operation
;; needs to be performed.
(push c res)))
res))

I would have been nice if I hadn't had to write this myself.

How do I query what files need to be recompiled?

[Ahmon Dancy]

http://www.cliki.net/asdf has this FAQ:

Q: How do I query what files need to be recompiled?

A: With ASDF 3, you can 
(asdf:required-components system :force nil
:force-not nil :keep-component 'asdf:cl-source-file :keep-operation
'asdf:compile-op)

However, with ASDF 3.1.6, I find that this does not work as
advertised:


;;; system1.asd
(asdf:defsystem :system1
:serial t
:default-component-class asdf:cl-source-file.cl
:components
((:file "one")
 (:file "two")
 (:file "three")))

cl-user(8): (asdf:compile-system :system1)
t

cl-user(9): (asdf:required-components :system1 
  :force nil :force-not nil
   :keep-component 'asdf:cl-source-file 
:keep-operation 'asdf:compile-op)
(# 
# 
#)


Is there a new way to achieve the same goal?

How do I query what files need to be recompiled?

[Ahmon Dancy]

http://www.cliki.net/asdf has this FAQ:

Q: How do I query what files need to be recompiled?

A: With ASDF 3, you can 
(asdf:required-components system :force nil
:force-not nil :keep-component 'asdf:cl-source-file :keep-operation
'asdf:compile-op)

However, with ASDF 3.1.6, I find that this does not work as
advertised:


;;; system1.asd
(asdf:defsystem :system1
:serial t
:default-component-class asdf:cl-source-file.cl
:components
((:file "one")
 (:file "two")
 (:file "three")))

cl-user(8): (asdf:compile-system :system1)
t

cl-user(9): (asdf:required-components :system1 
  :force nil :force-not nil
   :keep-component 'asdf:cl-source-file 
:keep-operation 'asdf:compile-op)
(# 
# 
#)


Is there a new way to achieve the same goal?

Re: [autofs] Two problems w/ autofs

[Ahmon Dancy]

 On Tue, 2009-02-17 at 15:52 -0800, Ahmon Dancy wrote:
  Hello Ian, et al.
  
  Using autofs-5.0.3-36 (built from Fedora 10 updates source RPM) on
  2.6.26.6-49.fc8 kernel.  We run w/ LOGGING=debug.
 
 You will need update your 2.6.26 based kernel with the latest kernel
 module patch before we go further with this. It can be found in the
 patches directory of the 5.0.4 tarball on kernel.org.

Is there any released fedora-supplied kernel (perhaps for Fedora 9
or 10) that has the necessary goods?  If the system in question needs
to be restarted for a kernel update, it may be a good time to update
the Fedora installation as well.

___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

[autofs] Two problems w/ autofs

[Ahmon Dancy]

Hello Ian, et al.

Using autofs-5.0.3-36 (built from Fedora 10 updates source RPM) on
2.6.26.6-49.fc8 kernel.  We run w/ LOGGING=debug.

We use autofs extensively for NFS multimounts and there are a few
issues that we're trying to get resolved:

Problem #1:

We us a TIMEOUT of 300 but there are often mounts that are never
expired, even if lsof shows no process is using the mount points in
question.   kill -USR1 doesn't help.

Example: /net/bb2 isn't expiring.

Relevant portion of /proc/mounts:

bb2:/ /net/bb2 nfs 
rw,nosuid,nodev,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nointr,proto=tcp,timeo=600,retrans=2,sec=sys,mountproto=udp,addr=192.168.95.79
 0 0
-hosts /net/bb2/acl autofs 
rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0
-hosts /net/bb2/home autofs 
rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0
-hosts /net/bb2/opt autofs 
rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0
-hosts /net/bb2/tmp autofs 
rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0
-hosts /net/bb2/usr autofs 
rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0
-hosts /net/bb2/var autofs 
rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0
bb2:/opt /net/bb2/opt nfs 
rw,nosuid,nodev,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nointr,proto=tcp,timeo=600,retrans=2,sec=sys,mountproto=udp,addr=192.168.95.79
 0 0

Sample log entry:

Feb 17 15:31:40 gemini automount[9397]: handle_packet_expire_indirect: token 
67811, name bb2
Feb 17 15:31:40 gemini automount[9397]: expiring path /net/bb2
Feb 17 15:31:40 gemini automount[9397]: umount_multi: path /net/bb2 incl 1
Feb 17 15:31:40 gemini automount[9397]: some offset mounts still present under 
/net/bb2
Feb 17 15:31:40 gemini automount[9397]: couldn't complete expire of /net/bb2
Feb 17 15:31:40 gemini automount[9397]: send_fail: token = 67811

Interestingly, there's no mention of /net/bb2/opt, which it would need
to umount first.


Problem #2:

One of the multimounts is misbehaving and not lazy-mounting.  The
problem seems to stem from a failure to do a lazy umount earlier:

Log entries for the umount attempt:

Feb 17 13:32:54 gemini automount[9397]: handle_packet: type = 4
Feb 17 13:32:54 gemini automount[9397]: handle_packet_expire_indirect: token 
67564, name cobweb
Feb 17 13:32:54 gemini automount[9397]: expiring path /net/cobweb
Feb 17 13:32:54 gemini automount[9397]: umount_multi: path /net/cobweb incl 1
Feb 17 13:32:54 gemini automount[9397]: umount_multi_triggers: umount offset 
/net/cobweb/home/ftp
Feb 17 13:32:54 gemini automount[9397]: umount_autofs_offset: offset 
/net/cobweb/home/ftp not mounted
Feb 17 13:32:54 gemini automount[9397]: umount_multi_triggers: umount offset 
/net/cobweb/home/patches
Feb 17 13:32:54 gemini automount[9397]: umount_autofs_offset: offset 
/net/cobweb/home/patches not mounted
Feb 17 13:32:54 gemini automount[9397]: umount_multi_triggers: umount offset 
/net/cobweb/www/sites/franzdownload
Feb 17 13:32:54 gemini automount[9397]: umount_autofs_offset: offset 
/net/cobweb/www/sites/franzdownload not mounted
Feb 17 13:32:54 gemini automount[9397]: some offset mounts still present under 
/net/cobweb
Feb 17 13:32:54 gemini automount[9397]: couldn't complete expire of /net/cobweb
Feb 17 13:32:54 gemini automount[9397]: send_fail: token = 67564

After this happened, accesses to /net/cobweb/home/ftp did not result
in an automatic mount, just an empty directory.


This is a production system so I can only do so much, but I can try
reasonable tests and supply debugging output.   Unfortunately I
haven't yet found a way to explicitly cause the broken scenario to
happen.

___
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Re: [htdig-dev] rundig: htdig -i and bug #1123810

[Ahmon Dancy]

  #1: bug #1123810 seems like an important bug with an easy fix.  What
   are the chances of getting it in?  I had a look at rundig in the CVS
   repository and it looks like it's still not done.
 
   Please submit the fix.

(diff against the trunk)
Index: installdir/rundig
===
RCS file: /cvsroot/htdig/htdig/installdir/rundig,v
retrieving revision 1.9
diff -u -r1.9 rundig
--- installdir/rundig   29 Dec 2003 08:49:05 -  1.9
+++ installdir/rundig   1 Mar 2006 23:44:16 -
@@ -30,7 +30,6 @@
 done
 
 # If -a specified, note the database directory to move the temp files correctly
-# TODO: Should also check for files relative to COMMONDIR.
 if [ -f $conffile ]
 then
 new_db_dir=`awk '/^[^#a-zA-Z]*database_dir/ { print $NF }'  $conffile`
@@ -38,6 +37,11 @@
 then
DBDIR=$new_db_dir
 fi
+new_dir=`awk '/^[^#a-zA-Z]*common_dir/ { print $NF }'  $conffile`
+if [ $new_dir !=  ]
+then
+   COMMONDIR=$new_dir
+fi
 else
 echo Config file $conffile cannot be found
 exit 1


 
  #2: How come rundig calls htdig with the -i flag by default?  Doing
   so makes it impossible (as far as I can tell) to use rundig to do
   incremental indexing.  
  
 
   Correct!  I don't use rundig myself..

So... what do we do about it?  I think rundig would be fine (w/ the
COMMONDIR fix above) and the removal of the default -i flag.  

 FYI:  A couple of us are in the process of reworking HtDig's code code for 
 HtDig 4.0.  You can see the progress reports here
 
 http://htdig.blogspot.org  http://opensource.rightnow.com/htdig.php

I checked it out.  It looks promising!

 I think the current version in the trunk of CVS is more or less
 DEAD.

Alright.  I'm using the htdig rpm from Fedora Core 4.  I can just
submit patches to whoever is maintaining the package at Redhat.
However, I do want to make sure that the patches are agreeable to you
first.


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
ht://Dig Developer mailing list:
htdig-dev@lists.sourceforge.net
List information (subscribe/unsubscribe, etc.)
https://lists.sourceforge.net/lists/listinfo/htdig-dev

[htdig-dev] rundig: htdig -i and bug #1123810

[Ahmon Dancy]

Hello htdig developers.

Two questions/comments:

#1: bug #1123810 seems like an important bug with an easy fix.  What
 are the chances of getting it in?  I had a look at rundig in the CVS
 repository and it looks like it's still not done.

#2: How come rundig calls htdig with the -i flag by default?  Doing
 so makes it impossible (as far as I can tell) to use rundig to do
 incremental indexing.  



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
ht://Dig Developer mailing list:
htdig-dev@lists.sourceforge.net
List information (subscribe/unsubscribe, etc.)
https://lists.sourceforge.net/lists/listinfo/htdig-dev

Re: [Nmh-workers] unseen sequence after inc into initially-empty folder

[Ahmon Dancy]

  I do agree that mp-hghmsg++ is simpler than the whole chunk of code
  (which I copied from folder_addmsg).  I do think that mp-lowmsg
  should be set to 1 if it was zero, though (since there is no message
  number 0).  Here's why:
 
 Both calls to folder_realloc() in inc.c use 'mp-lowoff', not 'mp-lowmsg'
 for the second argument 'int lo'.  In 'folder_read()', this value will be
 at least 1, so the particular code you mention won't fail.

Recall in my prior message that I said that it's the third check that
will fail:

if (mp-nummsg  0  lo  mp-lowmsg)
adios (NULL, BUG: called folder_realloc with lo (%d)  mp-lowmsg (%d),
   lo, mp-lowmsg);

If mp-lowmsg is not maintained properly (as it would be with the code
I suggested), it will remain 0.  The check above will fail because, as
you said, lo will be at least 1:

if (mp-nummsg  0  lo  mp-lowmsg)
=== translates to
if (100ish  0  1  0)


Let me mention, in case it wasn't clear, that I'm not speculating
here.  I went throught this whole experience when I originally tried
to fix the unseen sequence on empty folders bug.


 
 In principle, I agree wholeheartedly about rigorous maintenance of state
 variables.  The whole business of dealing with the variables in 
 'struct msgs' would be better handled with a C++ class, or just subroutines
 that are called when members need to be changed.

Indeed.

 
 However, the nmh code set is a bit of jumble, and I really worry about
 unintended side effects of a change that on the surface makes perfect sense.
 So at this point I'd want to study the handling of 'mp-lowmsg' before
 making the change.



___
Nmh-workers mailing list
[EMAIL PROTECTED]
http://mail.nongnu.org/mailman/listinfo/nmh-workers

Re: Retry even when Connection Refused

[Ahmon Dancy]

 Ahmon Dancy [EMAIL PROTECTED] writes:
 
  I'll apply it shortly.
 
  Thanks.
 
 Applied now.

Great.

 
  Is there a wget-announce mailing list?
 
 No.

Alright.  Is there a rough estimate for the next release date?

Re: Retry even when Connection Refused

[Ahmon Dancy]

 Ahmon Dancy [EMAIL PROTECTED] writes:
 
  Please consider this patch:
 [...]
 
 It looks good to me.  Cheating about whether the connection was
 really refused looks slightly wrong, but on the other hand, changing
 every single place that looks at the result is tedious.

I did consider that but I came to the same conclusion.

 
 Please note that patches should be sent as unified or context diffs
 (`diff -u' or `diff -c').

Sorry about that. :)

 
 I'll apply it shortly.

Thanks.

Is there a wget-announce mailing list?

boot floppy documentation question

[Ahmon Dancy]

The docs say:

# cd /usr/share/grub/i386-pc
# dd if=stage1 of=/dev/fd0 bs=512 count=1
1+0 records in
1+0 records out
# dd if=stage2 of=/dev/fd0 bs=512 seek=1
153+1 records in
153+1 records out
#


Considering the fact that 'stage1' is 512 bytes anyway, wouldn't it be simpler 
to specify:  cat stage1 stage2  /dev/fd0  ?


___
Bug-grub mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-grub

[htdig] gethostbyname result caching

[Ahmon Dancy]

Has there been any discussion on caching the results of gethostbyname
(in Connection.cc) so that a nameserver isn't continuously hammered w/
the same lookup over and over?

___
htdig-general mailing list [EMAIL PROTECTED]
To unsubscribe, send a message to [EMAIL PROTECTED] with a 
subject of unsubscribe
FAQ: http://htdig.sourceforge.net/FAQ.html

[htdig] connection reuse

[Ahmon Dancy]

 I don't recall it being discussed before.  Of course, if you set up a
 caching-only name server right on the machine that runs htdig, the
 nameserver requests would likely become a non-issue.  That's probably
 a cleaner solution than putting caching right into htdig, although it
 might be easy enough to add an IP address field to the Server class and
 have htdig use that for connections.

Alright.  On a semi-related note, is there work being done to keep a
TCP connection to a particular server alive for multiple requests?

___
htdig-general mailing list [EMAIL PROTECTED]
To unsubscribe, send a message to [EMAIL PROTECTED] with a 
subject of unsubscribe
FAQ: http://htdig.sourceforge.net/FAQ.html

Re: [htdig] connection reuse

[Ahmon Dancy]

 According to Ahmon Dancy:
  Alright.  On a semi-related note, is there work being done to keep a
  TCP connection to a particular server alive for multiple requests?
 
 Yes, in 3.2.0b4.  See the persistent_connections attribute.  It needs
 more testing, and possibly some more debugging, but it is functional
 right now.

Sweet.  I'll wait for the 3.2 release.


___
htdig-general mailing list [EMAIL PROTECTED]
To unsubscribe, send a message to [EMAIL PROTECTED] with a 
subject of unsubscribe
FAQ: http://htdig.sourceforge.net/FAQ.html

Re: [htdig] gethostbyname result caching

[Ahmon Dancy]

 According to Ahmon Dancy:
  Has there been any discussion on caching the results of gethostbyname
  (in Connection.cc) so that a nameserver isn't continuously hammered w/
  the same lookup over and over?
 
 I don't recall it being discussed before.  Of course, if you set up a
 caching-only name server right on the machine that runs htdig, the
 nameserver requests would likely become a non-issue.  That's probably
 a cleaner solution than putting caching right into htdig, although it
 might be easy enough to add an IP address field to the Server class and
 have htdig use that for connections.

I think the latter approach should be considered.  It's unfortunate to
recommend that folks do extra systems admin stuff to make htdig work
more efficiently.  In my case, 172 bytes of unnecessary network data
transfer occurs due to DNS lookups.  We're indexing 58,100 pages.
That comes out to 9.5MB of useless data transfer that could be
eliminated (seemingly) easily.


___
htdig-general mailing list [EMAIL PROTECTED]
To unsubscribe, send a message to [EMAIL PROTECTED] with a 
subject of unsubscribe
FAQ: http://htdig.sourceforge.net/FAQ.html

Re: [htdig] Re: htdig questoins

[Ahmon Dancy]

 I see absolutely nothing security-related about this, but it is a 
 potential bug report, so we should consider it.

It's definitely not a security patch.  That was a miscommunication.

 I'd be glad to revise this *if* someone can confirm that EAGAIN is 
 portable and/or in some spec like POSIX.
 

The best I can do is confirm that EAGAIN exists on the following
operating systems:

aix 4.2
tru64 5.0a (where it is an alias for EWOULDBLOCK)
freebsd 4.0 (where EWOULDBLOCK is an alias for it)
hpux 10.20
irix 6.5 (where EWOULDBLOCK is an alias for it)

You could also do:

#ifdef EAGAIN
my patch
#endif

or perhaps conditionalize on linux.


___
htdig-general mailing list [EMAIL PROTECTED]
To unsubscribe, send a message to [EMAIL PROTECTED] with a 
subject of unsubscribe
FAQ: http://htdig.sourceforge.net/FAQ.html

Re: [htdig] htdig and the '-i' option

[Ahmon Dancy]

 According to Ahmon Dancy:
  After reading the documentation and FAQ, It's not clear to me why one
  would choose to or choose not to use the -i option to htdig.  Can
  anyone give me some insight on this please?  Does not using '-i' make
  the dig faster?  What does htdig do with old database if '-i' isn't
  specified?
 
 Yes, not using -i will make the dig faster if you have an existing
 database.  The -i option causes htdig to wipe out the existing database,
 if there is one, and dig all documents.
 
 Without -i and with an existing database, htdig goes into update mode,
 where it checks all URLs in the database and in start_url, to see if
 they've changed since the last dig.  If they have, or if they're in
 start_url but not in the database, they're reindexed, and any links in
 these documents will similarly be rechecked.
 
 Generally, checking to see if the documents have been modified is much
 quicker than re-fetching and re-parsing all documents every time.

Great.  I think I understand.   For what I'm doing, -i is fine because
all the output is CGI generated (which, presumably, means that it will
always be newer that previous information).

Thank you for your help.  I wonder if you know the answer to this one
as well:

Can you explain each of these files (i.e., what good are they).

db.words.db
db.docs.index
db.docdb
db.wordlist

dn.wordlist and word.db seem to go together...  and db.docs.index and
db.docsb seem to go together...  But I don't understand their
relationship.

___
htdig-general mailing list [EMAIL PROTECTED]
To unsubscribe, send a message to [EMAIL PROTECTED] with a 
subject of unsubscribe
FAQ: http://htdig.sourceforge.net/FAQ.html

Re: [LINUX-ABIT] Mailing list being shut down

[Ahmon Dancy]

I second that emotion.


On Tue, 10 Jul 2001, Robert Davies wrote:
 On Tuesday 10 July 2001 16:52, you wrote:
  On Mon, Jul 09, 2001 at 08:07:57PM -0500, Robert A. Hayden wrote:
 
   As a result of losing my T1, I'll be forced to take the linux-abit
   mailng list down at that time.
 
  Why not move the list to Yahoo.  I've heard that they offer free mailing
  list.
 
 I'd rather worry about that being a one way ticket, if it's on an open system 
 then Robert Hayden could easily take the list back if he wanted, when 
 circumstances improve.
 
 Secondly I'm sure a lot of ppl aren't too happy at giving companies their 
 email addresses, there's enough spam in the world as it is.
 
 Rob
 --
 =-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
 =-body of unsubscribe linux-abit. -=
 
 



--
=-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
=-body of unsubscribe linux-abit. -=

[LINUX-ABIT] lockups

[Ahmon Dancy]

On the topic of various ways to try to fix the lockup problem..

perhaps we should try a different approach.  

Does anyone know the exact nature of the lockup?  i.e.:

Is the kernel getting stuck in a loop somewhere?

Is the kernel waiting for something to happen that will never happen?

Is it an actual hardware lockup? i.e., Is the CPU trying to talk to hardware 
that is no longer responding?


Unfortunately, the best person to answer this is probably Andre.. but he 
doesn't experience the problem.


--
=-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
=-body of "unsubscribe linux-abit". -=

Re: [LINUX-ABIT] Re: Problem with UDMA 4 - deadlocking machine

[Ahmon Dancy]

On Mon, 18 Dec 2000, Zdenek Kabelac wrote:
  On Mon, 18 Dec 2000, Zdenek Kabelac wrote:
   BP6 hpt366 is completely bad piece of hardware (I hope it's not that
   bad)
  
  Unfortunately this is your answer. It will even lockup using PIO mode.
  It also locks up under Windoze, so it's not a "linux driver problem".
 
 Why its not locking with UDMA2 - just with UDMA4 and concurently running
 interrupts ??

I suspect that going to UDMA2 just makes the problem harder to reproduce due to 
the reduced load.

 
 Couldn't this be just some problem with timers ?
 How can you be sure its all just hardware bug ?
 
 Also when this lost interrupt is detected while my computer
 is still running for next five seconds or so before it completele freezes?

I've always wondered this as well.

 
 I think there could be exist some software solution for this
 (just like there are some software fixies for Pentium bugs).
 
 But I do not have technical knowledge to reprogram ATA controler
 (not mentioning I have no idea where the documentation for them
 could be downloaded)

--
=-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
=-body of "unsubscribe linux-abit". -=

Re: [LINUX-ABIT] Bus Mastering

[Ahmon Dancy]

So, this differs from regular DMA in that:
  It can do scatter-gather.
  The normal dma controller is not involved (?)


On Wed, 13 Dec 2000, [EMAIL PROTECTED] (Rogier Wolff) wrote:
 Ahmon Dancy wrote:
  Regarding bus mastering slots:
 
  Can anyone give a brief technical explanation of what bus mastering
  slots are about and what card are likely to be bus mastering?
 
 In the old days the CPU would be programmed to get data from IO cards
 (or put the data in). Programmed IO. 
 
 Nowadays many cards can be told to go get the data themselves. So when
 I transfer 1Mb of data from my harddisk, the CPU has to tell the chip
 about 250 times where to put the data, and the harddisk-chip will do
 the rest by itself. In the old days, the CPU would have had to do a
 few instructions for every one or two bytes! 
 
 So nowadays, network cards, sound cards, SCSI cards all do "bus
 mastering" and gather the data they need from memory themselves.
 
 To do this, they request the system bus using a signal called "bus
 request". When the system is ready for this device, the system will
 signal "bus grant", and the device is allowed to access main memory. 
 
 These signals need to be separate: there can be a network packet
 coming in at the same time as the harddisk having some data ready.
 
 If these two cards were to share a busrequest /busgrant signal, they
 would both signal "bus request" at the same time, which would be
 recognized by the board just fine. However then, when the bus grant
 would happen, they would both start to access the bus at the same
 time. (compare this with two green lights on different roads with a
 traffic light...)
 
 So, one card may say: write 1200 to address 5070 and the other may
 want: write 0034 to 0608. The result might be 1234 going to address
 5678! (Or something completely different).
 
 Now, on the BP6 (and a lot of other boards), two slots share a
 busrequest, and busgrant line. You get to use only one of them with a
 card that uses busmastering.
 
 A second video card is an option. Video cards rarely use bus mastering. 
 
 The multi-port serial cards that I've written drivers for also don't
 use busmastering. I'm told that RTL8139 cards don't use busmastering
 either.
 
 Oh, the PCI people designed the Interrupt lines in such a way that
 they can be shared between different devices. So all PCI device
 drivers should be able to handle this situation. 
 
   Roger. 
 
 -- 
 ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
 *-- BitWizard writes Linux device drivers for any device you may have! --*
 * There are old pilots, and there are bold pilots. 
 * There are also old, bald pilots. 
 
 



--
=-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
=-body of "unsubscribe linux-abit". -=

[LINUX-ABIT] Bus Mastering

[Ahmon Dancy]

Regarding bus mastering slots:

Can anyone give a brief technical explanation of what bus mastering slots are 
about and what card are likely to be bus mastering?

--
=-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
=-body of "unsubscribe linux-abit". -=

[LINUX-ABIT] 2.2.18

[Ahmon Dancy]

1) Where does one locate this 2.2.18 kernel that people keep talking about?  

2) I would like to also thank Andre for his IDE work.  It is probably one of 
the most important contributions to linux speed on PCs.

3) I have a broken (while trying to do the capacitor trick) BP6 mobo I can 
donate. :)  Symptoms:
System initializes up to the point there it should show  ", 2 Processors".  It 
hangs at that point.  The power supply fan drops to a low speed so I'm guessing 
that I make a short circuit somewhere.


--
=-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
=-body of "unsubscribe linux-abit". -=

Re: [LINUX-ABIT] 2.2.18

[Ahmon Dancy]

I mean the kernel itself (not the IDE patches for it)

On Tue, 5 Dec 2000, Andre Hedrick wrote:
 
 http://www.kernel.org/pub/linux/kernel/people/hedrick/ide-2.2.18/
 
 
 --
 =-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
 =-body of "unsubscribe linux-abit". -=
 
 



--
=-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
=-body of "unsubscribe linux-abit". -=

Re: [LINUX-ABIT] Re: BP6 Caps - was cautionary tale

[Ahmon Dancy]

On Tue, 5 Dec 2000, Vidiot wrote:
  Is there an easy way to identify the version of the board without taking 
the
  board out?
 
 yes. it's called a mirror. use it to look at the lower part of the ISA
 slot. there is a sticker. if it annoiunces v1.0 you're all set. if you
 have v1.1 you may be having an incorrect board. however, it's easy to be
 changed if you know how to handle a soldering iron.
 
 There isn't much space between the ISA connector and the chassis, making it
 difficult to even do that.

Indeed.  An easier way is to go into the BIOS setup.. go to the place where you 
can see the VTT voltage (and other voltage settings).  The VTT should be around 
1.5.  It will fluctuate a little. If it's between 1.48 and 1.52 (which is what 
I see on my rev 1.0 mobo), you're all good.  If you see it drop to like 1.42 a 
bunch, you have the bad one.

 
 Using a soldering iron and all that goes along with it is not a problem.
 What is missing from this information is the location of the cap and what
 it is really supposed to be.  Is that info available somewhere?

http://bp6.gamesquad.net/Q6fix.phtml

This also tells you how to identify the bogus voltage regulator.




--
=-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
=-body of "unsubscribe linux-abit". -=

Re: [LINUX-ABIT] New to the list

[Ahmon Dancy]

On Fri, 1 Dec 2000, Robert Davies wrote:
  I narrowed down some stuff last night (I spent hours on it.. I'm beat).
 Here's
  my setup:
 
  hda: CDROM drive
  hdc: Quantum 12GB (ATA/33 mode)
  hde: IBM 20GB (ATA/33 mode)
  hdg: IBM 46GB (ATA/100 in ATA/66 mode)
 
  DMA mode is enabled on all.
 
  All I have to do to hang the system (on 2.4.0-test11 and 2.2.17) is: (by
 the
  way, I also made a uniprocessor kernel and this still would hang)
 
 You may also like to try backing off from ATA-66 and setting it to ATA-33.
 
 I found the BP6 would hard lock up totally, with 2 CPUs regularly, without
 qq_beta, which was superceded by qq, and ru bioses.

I'm using the RU bios now.. Upgraded last night.. had no effect.

As far as ATA-33, goes.. .what is the technical name for this mode?  It appears 
that ATA-66 is UDMA 4.  

--
=-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
=-body of "unsubscribe linux-abit". -=

[LINUX-ABIT] New to the list

[Ahmon Dancy]

Hello everybody.

What's the latest word on BP6 stability under linux?  I've been doing
testing for the last several hours... trying to find a stable
configuration.  Likely I have an easily reproducible test case that I can
try each time I change something.  
 
My test case consists of using dump/restore to copy from one filesystem to
another.  The source filesystem is on ide3 and the destination is on ide4.  
I'm using a 2.4.0-test11 kernel which prints an error message (APIC error
on CPUX) when the badness occurs.  DMA is enabled on all disks.

It seems clear that the problem has something to do w/ a combination of
the following:

SMP
DMA on HPT366 controller
IRQ sharing

I'm hoping to find a solution.  I'd hate to turn of DMA mode.  It makes an
enormous difference in disk operation performance.


--
=-  To unsubscribe, email [EMAIL PROTECTED] with the   -=
=-body of "unsubscribe linux-abit". -=

general/5254: Bogus URL returns output

[Ahmon Dancy]

Number: 5254
Category:   general
Synopsis:   Bogus URL returns output
Confidential:   no
Severity:   non-critical
Priority:   medium
Responsible:apache
State:  open
Class:  sw-bug
Submitter-Id:   apache
Arrival-Date:   Thu Nov  4 11:20:02 PST 1999
Last-Modified:
Originator: [EMAIL PROTECTED]
Organization:
apache
Release:1.3.9
Environment:
  SunOS tanya 5.5.1 Generic_103640-27 sun4u sparc SUNW,Ultra-1
Description:
This URL works when it should not:

http://www.franz.com/index.html/xyz.html.

There is no file index.html/xyz.html

I'm trying this test on a mirror of the same site (on a different host) and
apache properly reports error 404 in that case.  The only important difference
that I can think of between the two apaches is that the one that doesn't
work properly has server-side includes turned on for all .html files.

How-To-Repeat:
Access http://www.franz.com/index.html/xyz.sdf
Fix:

Audit-Trail:
Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include [EMAIL PROTECTED] in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as general/1098: or  ]
[Re: general/1098:).  If the subject doesn't match this   ]
[pattern, your message will be misfiled and ignored.  The   ]
[apbugs address is not added to the Cc line of messages from  ]
[the database automatically because of the potential for mail   ]
[loops.  If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request from a  ]
[developer.  Reply only with text; DO NOT SEND ATTACHMENTS! ]

Re: general/5254: Bogus URL returns output

[Ahmon Dancy]

Thanks. 

mod_mime/2979: Can't undo an earlier AddHandler

[Ahmon Dancy]

Number: 2979
Category:   mod_mime
Synopsis:   Can't undo an earlier AddHandler
Confidential:   no
Severity:   non-critical
Priority:   medium
Responsible:apache
State:  open
Class:  sw-bug
Submitter-Id:   apache
Arrival-Date:   Wed Sep  9 16:20:00 PDT 1998
Last-Modified:
Originator: [EMAIL PROTECTED]
Organization:
apache
Release:1.3
Environment:
SunOS tanya 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-1
Description:
I'd like to have a way to undo an AddHandler that a previously-parsed
configuration file may have added.  I understand that I can just do another
AddHandler and it would override the previous AddHandler... but, as far as
I can tell, there is no way to revert to the default handler that would be used
if no prior AddHandler had been seen.  

Here's our story:

Our main tree has an AddHandler server-parsed .html, to treat _all_ .html
files as SSI's.  However, in a subtree, I don't want this behaviour.  I want
the .html files to be handled the way they would have been w/o the AddHandler.
How-To-Repeat:

Fix:
I'd like something like:

DelHandler .html

or

AddHandler none .html
Audit-Trail:
Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include [EMAIL PROTECTED] in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]
[If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request ]
[from a developer.  ]
[Reply only with text; DO NOT SEND ATTACHMENTS! ]