FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-30-2011, 01:45 PM
Andreas Tille
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

Hi again,

I would like to repeat my question about UDD access from alioth (or one
/ both of its successors): Is there anybody working to reenable the UDD
access?

Kind regards and thanks for maintaining Alioth

Andreas.

On Wed, May 25, 2011 at 09:25:37AM +0200, Andreas Tille wrote:
> It also needs to have access
> to UDD, which was possible on alioth[1]
>
> ~$ psql service=udd
> psql: ERROR: service file "/etc/postgresql-common/pg_service.conf" not found
>
> Will this UDD access be enabled on vasks? On wagner I get a different
> error:
>
> $ psql service=udd
> psql: definition of service "udd" not found
>
> As a wishlist "problem": Please install mc on vasks.
>
> Kind regards
>
> Andreas.
>
> [1] http://wiki.debian.org/UltimateDebianDatabase

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110530134519.GB19912@an3as.eu">http://lists.debian.org/20110530134519.GB19912@an3as.eu
 
Old 06-14-2011, 02:49 PM
Gerfried Fuchs
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

Hi!

* Stephen Gran <sgran@debian.org> [2011-06-11 16:06:58 CEST]:
> This one time, at band camp, Andreas Tille said:
> > I would like to repeat my question about UDD access from alioth (or one
> > / both of its successors): Is there anybody working to reenable the UDD
> > access?
>
> This is now reenabled. I had hoped to get postgres streaming
> replication working, but unfortunately udd is running on a 32bit system,
> while wagner and vasks are 64bit, so it didn't work out. localhost/5441
> will get you access to udd over a tunnel for now until we can think of
> something better/different.

Thanks. Some findings about this: Formerly a plain "service=udd" was
working as convenience. Is it planned to put the pg_service.conf into
place again? That way the backend connection could be transparently
switched (though, my guess would be that the tunnel is there for the
same purpose)

Also, it is working on wagner, but not on vasks. As I understood it
this is intentional. On the other hand, the public_html sites are hosted
on vasks, not on wagner, so services that would want to query UDD and
offer results are out of scope in the new alioth setup.

I wonder if this is bothering just myself and whether I rather should
provide myself with some scripts that I call via ssh to vasks and have
the output locally (and offer access to the script to other users and
document it in my alioth page) or whether this is something that can be
reconsidered to get working again and that are others bitten by, too.

From my understanding, deploying stuff on UDD is to be done after a
test period or at least after the involved people consider it useful for
ther broader audience, which the current approach has cut off now. For
instance, I still had used my stable-RC.php page instead of lucas'
UDD/bugs.cgi script because of some finer differences that might be
considered personal preferences but which did suit my workflow better
(and I have received input for that from others, too).

My unarchived-bugs.php page is nowhere found yet on UDD or QA site and
does also offer digging up targets of packages for looking at bugreports
for inconsistencies that happened over time, for easier bug triaging.

Also, I was asked today whether it is possible to query the UDD for
bugreports against unknown packages, and I would have liked to offer an
interface for that for people to look at so they can be more
conveniently digged up, only to find out that this possibility is cut
off now, at least in the way it was possible before and to my
understanding the encouraged way to go, the main background behind
having access to UDD from alioth in the first place.

Generating those files statically and copy them over through a specific
ssh key chained command when the pages are not that regularly looked at
would unneededly add load to UDD that I really would like to avoid. For
the same purpose I even added a caching mechanism in the script that
did hook in on constant reloads of the page. I intentionally did do
these things in a defensive way.

Is there some place that is willing to host such service queries that
probably only a handful people would be interested to look at (because
QA work is boring but needs to get done anyway) that has both the
possibility to do on-demand website generation and also has UDD read
access? I'm not opposed to move the pages, I just would like to know
_where_ to, and it would had been rather convenient to have been made
aware of disabling that possibility beforehand, but I can understand
that this usage might not be that widely known, even though I mentioned
it in serveral different places from time to time ...

<tl;dr>Is there some host for php/cgi and UDD access?

Thanks,
Rhonda
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110614144922.GA447@anguilla.debian.or.at">http://lists.debian.org/20110614144922.GA447@anguilla.debian.or.at
 
Old 06-16-2011, 11:36 AM
Andreas Tille
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

On Tue, Jun 14, 2011 at 09:03:25PM +0100, Stephen Gran wrote:
> > Thanks. Some findings about this: Formerly a plain "service=udd" was
> > working as convenience. Is it planned to put the pg_service.conf into
> > place again? That way the backend connection could be transparently
> > switched (though, my guess would be that the tunnel is there for the
> > same purpose)
>
> I've restored the pg_service config now.

Thanks.

> > Also, it is working on wagner, but not on vasks. As I understood it
> > this is intentional. On the other hand, the public_html sites are hosted
> > on vasks, not on wagner, so services that would want to query UDD and
> > offer results are out of scope in the new alioth setup.

That's also very annoying for the Blends pages.

> [ lot more good reasons snipped ]
>
> <alioth admin hat>
> I have to say that I'm not very happy about general purpose hosting on
> the 'alioth' servers. While I agree QA work is useful and should be
> encouraged rather than discouraged, I don't know if alioth is the place
> for development work of this sort.
> </alioth admin hat>

Regarding the Blends pages: I have set up blends.debian.net which is
running a clone of UDD and the development of the pages is happening
there. So the code which is rolled out at Alioth (and successors) is
tested. I'm just using blends.alioth.d.o as the official address
because I'm trusting DSA for providing a reliable service which I can
not guarantee for blends.d.n. I'm not using alioth as development
playground.

> <dsa hat>
> qa.d.o has a dedicated machine, udd has a dedicated machine, and I'm
> sure it would be straight forward enough to set up a playpen on one
> or the other of those machines for DDs who want to do QA tasks without
> formally joining the QA team (just a gid debian writable subdirectory
> of the web root where users could create their own spaces would probably
> be sufficient?). This is just musing off the top of my head - I don't
> speak for the QA team or lucas about access to these services - the
> machines are open to all DDs, however, so I don't see any compelling
> issues to be resolved off hand.
> </dsa hat>

As far as I understood the main concern of Gerfried was that UDD access
is possible on the "wrong" machine. In my case it is the problem that I
can perfectly generate the Blends pages on wagner I need to sync them
afterwards to vasks. While in my case this is possible for those static
pages it is just not straightforeward and I would love to understand the
motivation behind the constraint nont to enable UDD access on vasks. (I
actually do not understand what is the sense of having UDD access on
wagner - I would see *only* a need on vasks.)

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110616113619.GG6440@an3as.eu">http://lists.debian.org/20110616113619.GG6440@an3as.eu
 

Thread Tools




All times are GMT. The time now is 02:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org