You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(40) |
Sep
(2) |
Oct
(40) |
Nov
(12) |
Dec
(79) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(62) |
Feb
(12) |
Mar
(19) |
Apr
(15) |
May
(22) |
Jun
(20) |
Jul
(23) |
Aug
(28) |
Sep
(74) |
Oct
(74) |
Nov
(80) |
Dec
(203) |
2003 |
Jan
(65) |
Feb
(160) |
Mar
(161) |
Apr
(105) |
May
(87) |
Jun
(48) |
Jul
(71) |
Aug
(130) |
Sep
(112) |
Oct
(206) |
Nov
(108) |
Dec
(84) |
2004 |
Jan
(309) |
Feb
(128) |
Mar
(246) |
Apr
(266) |
May
(449) |
Jun
(239) |
Jul
(184) |
Aug
(152) |
Sep
(151) |
Oct
(305) |
Nov
(193) |
Dec
(167) |
2005 |
Jan
(182) |
Feb
(248) |
Mar
(191) |
Apr
(256) |
May
(152) |
Jun
(55) |
Jul
(120) |
Aug
(103) |
Sep
(125) |
Oct
(85) |
Nov
(85) |
Dec
(64) |
2006 |
Jan
(165) |
Feb
(148) |
Mar
(120) |
Apr
(85) |
May
(100) |
Jun
(69) |
Jul
(86) |
Aug
(157) |
Sep
(103) |
Oct
(101) |
Nov
(134) |
Dec
(178) |
2007 |
Jan
(110) |
Feb
(67) |
Mar
(224) |
Apr
(108) |
May
(87) |
Jun
(40) |
Jul
(64) |
Aug
(68) |
Sep
(70) |
Oct
(82) |
Nov
(48) |
Dec
(74) |
2008 |
Jan
(74) |
Feb
(102) |
Mar
(47) |
Apr
(29) |
May
(40) |
Jun
(18) |
Jul
(19) |
Aug
(88) |
Sep
(69) |
Oct
(43) |
Nov
(13) |
Dec
(25) |
2009 |
Jan
(49) |
Feb
(64) |
Mar
(47) |
Apr
(38) |
May
(23) |
Jun
(41) |
Jul
(72) |
Aug
(49) |
Sep
(44) |
Oct
(35) |
Nov
(7) |
Dec
(56) |
2010 |
Jan
(171) |
Feb
(42) |
Mar
(31) |
Apr
(68) |
May
(26) |
Jun
(8) |
Jul
(36) |
Aug
(28) |
Sep
(31) |
Oct
(40) |
Nov
(3) |
Dec
(5) |
2011 |
Jan
(2) |
Feb
(5) |
Mar
(6) |
Apr
(12) |
May
(6) |
Jun
(15) |
Jul
(17) |
Aug
(7) |
Sep
(13) |
Oct
(30) |
Nov
(17) |
Dec
(4) |
2012 |
Jan
(5) |
Feb
(8) |
Mar
(7) |
Apr
(11) |
May
(5) |
Jun
|
Jul
(15) |
Aug
(25) |
Sep
(23) |
Oct
(18) |
Nov
(14) |
Dec
(12) |
2013 |
Jan
(18) |
Feb
(8) |
Mar
(9) |
Apr
|
May
|
Jun
(6) |
Jul
(18) |
Aug
(6) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(16) |
2014 |
Jan
(13) |
Feb
(22) |
Mar
(10) |
Apr
|
May
(8) |
Jun
(23) |
Jul
(17) |
Aug
(3) |
Sep
(22) |
Oct
(34) |
Nov
(4) |
Dec
(2) |
2015 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(3) |
May
(19) |
Jun
(33) |
Jul
(11) |
Aug
(9) |
Sep
|
Oct
|
Nov
(15) |
Dec
(7) |
2016 |
Jan
(13) |
Feb
(9) |
Mar
(5) |
Apr
(8) |
May
(2) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(1) |
Nov
|
Dec
(1) |
2017 |
Jan
(11) |
Feb
(8) |
Mar
(8) |
Apr
(7) |
May
|
Jun
(7) |
Jul
|
Aug
(9) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(8) |
Sep
(25) |
Oct
(4) |
Nov
(2) |
Dec
(3) |
2019 |
Jan
(20) |
Feb
(26) |
Mar
(18) |
Apr
(2) |
May
(5) |
Jun
(1) |
Jul
(9) |
Aug
(8) |
Sep
(8) |
Oct
(21) |
Nov
(8) |
Dec
(1) |
2020 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(15) |
May
(6) |
Jun
(2) |
Jul
(7) |
Aug
(5) |
Sep
(4) |
Oct
|
Nov
(5) |
Dec
(5) |
2021 |
Jan
|
Feb
(15) |
Mar
(50) |
Apr
(16) |
May
(22) |
Jun
(20) |
Jul
(5) |
Aug
(19) |
Sep
(1) |
Oct
(1) |
Nov
(42) |
Dec
(16) |
2022 |
Jan
(9) |
Feb
(5) |
Mar
(2) |
Apr
(6) |
May
(2) |
Jun
(10) |
Jul
(15) |
Aug
(9) |
Sep
(32) |
Oct
|
Nov
(14) |
Dec
(10) |
2023 |
Jan
(7) |
Feb
(6) |
Mar
(11) |
Apr
(16) |
May
(14) |
Jun
(7) |
Jul
(17) |
Aug
(1) |
Sep
|
Oct
(44) |
Nov
(24) |
Dec
(13) |
2024 |
Jan
(1) |
Feb
(25) |
Mar
(9) |
Apr
(10) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: John P. R. <ro...@cs...> - 2023-11-07 17:26:21
|
Hello Ivanov: In message <bf0...@ri...>, iva...@ri... writes: >On 2023-11-06 23:13, John P. Rouillard wrote: >> It might be a useful enhancement to support 'service' directly in >> config.ini. It would be useful when running one roundup server serving >> multiple trackers. >> >> If you want to move forward with Roundup and run multiple trackers >> with one Roundup server instance, we can work on getting support for >> specifying the 'service' in config.ini. You would need to test using >> the current development code. > >Thank you. At the moment I plan to install only one tracker, but I think >it would be nice to have such an option. When you implement this, I will >be happy to test it. Since it only took a couple of hours, I implemented it in: changeset: 7696:4af0d235b570 tag: tip user: John Rouillard <ro...@ie...> date: Tue Nov 07 12:11:37 2023 -0500 files: CHANGES.txt doc/reference.txt roundup/backends/back_postgresql.py roundup/backends/rdbms_common.py roundup/configuration.py description: feat(db): support using postgresql service connection file Add new service rdbms config option to set the service name to be used with a postgresql service connection file. This can be done using the PGSERVICE environment variable for a single instance tracker server. For a multi-instance server this per-tracker config option is needed. Note that settings (host, user, (db)name...) in config.ini file will override the service connection file setting. Also setting PGSERVICE and service will use the service setting. You can pull the code from the repo using mercurial: hg clone http://hg.code.sf.net/p/roundup/code roundup The issue is tracked at: https://issues.roundup-tracker.org/issue2551299 You can send email to the is...@ro... with the subject: [issue2551299] Connecting to PostgreSQL database using pg_service.conf to followup with any issues or just reply here. Have a great week. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: <iva...@ri...> - 2023-11-07 00:35:18
|
Hello John! On 2023-11-06 23:13, John P. Rouillard wrote: > > BTW we have docker images at hub.docker.com look for Roundup. Thank you. I prefer CI tools and Git for delivering and updating web applications. > Try this. Set the environment variable: > > PGSERVICE=your_service_name > > Then remove any values for the settings: > > host, port, user, password, and name > > in the rdbms section of the tracker's config.ini. (If you are not > setting some of those values in your pg_service.conf, set them in > config.ini.) Make sure the rdbms backend setting is set to postgresql. > > If your pg_service.conf file looks like: > > [roundup_roundup] > host=127.0.0.1 > port=5432 > user=rounduptest > password=rounduptest > dbname=rounduptest > > (the defaults for demo mode), run: > > roundup-admin -i tracker_home list status > > and see if you get a connection error. Excellent! Thank you very much. I will try it. > psycopg2 looks like it can use a "service=service_name" in its connect > method. (Working from https://github.com/psycopg/psycopg2/issues/926.) Django can use psycopg2/psycopg3 in a similar way. Since version 4.0, you can simply use the service parameter to connect to PostgreSQL without even specifying the database name. If you are interested, details can be found here: https://code.djangoproject.com/ticket/32292 > It might be a useful enhancement to support 'service' directly in > config.ini. It would be useful when running one roundup server serving > multiple trackers. > > If you want to move forward with Roundup and run multiple trackers > with one Roundup server instance, we can work on getting support for > specifying the 'service' in config.ini. You would need to test using > the current development code. Thank you. At the moment I plan to install only one tracker, but I think it would be nice to have such an option. When you implement this, I will be happy to test it. > Let me know how this works for you. Well, of course. -- With appreciation, Ivanov |
From: John P. R. <ro...@cs...> - 2023-11-06 23:13:26
|
Hello Ivanov: In message <82a...@ri...>, iva...@ri... writes: >I'm interested in Roundup Tracker and am currently exploring its >capabilities. Thanks for your interest. >Now I have a question regarding its use with PostgreSQL. > >I'm using containerized application servers behind a reverse proxy. BTW we have docker images at hub.docker.com look for Roundup. >My current setup has the PGSERVICE environment variable set for each >application server, so that psycopg2 can connect to the PostgreSQL >database using connection information from the pg_service.conf file. It >allows me to avoid storing database credentials in application-related >configuration files. > >Is there a way that Roundup Tracker can avoid using the default database >settings and use the values from pg_service.conf to connect to the >database? There is no explicit support in Roundup for this. However, libpq (which psycopg2 uses) should just use the environment variable provided Roundup doesn't override it. (https://www.postgresql.org/docs/current/libpq-envars.html) Try this. Set the environment variable: PGSERVICE=your_service_name Then remove any values for the settings: host, port, user, password, and name in the rdbms section of the tracker's config.ini. (If you are not setting some of those values in your pg_service.conf, set them in config.ini.) Make sure the rdbms backend setting is set to postgresql. If your pg_service.conf file looks like: [roundup_roundup] host=127.0.0.1 port=5432 user=rounduptest password=rounduptest dbname=rounduptest (the defaults for demo mode), run: roundup-admin -i tracker_home list status and see if you get a connection error. I set thing up as above and it worked for me. It displayed the statuses for the demo tracker. roundup-admin picked up the settings from the environment variable and the config file. I am using the current development tip of the default branch. But nothing done since release 2.3.0 should affect this AFAICT. I suspect the same method will work for starting the web frontend, or other roundup-* commands. If this works, it gives you what you want as long as you are ok with supporting only one tracker per container. psycopg2 looks like it can use a "service=service_name" in its connect method. (Working from https://github.com/psycopg/psycopg2/issues/926.) It might be a useful enhancement to support 'service' directly in config.ini. It would be useful when running one roundup server serving multiple trackers. If you want to move forward with Roundup and run multiple trackers with one Roundup server instance, we can work on getting support for specifying the 'service' in config.ini. You would need to test using the current development code. Let me know how this works for you. Have a great week. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: <iva...@ri...> - 2023-11-06 19:40:29
|
Hello! I'm interested in Roundup Tracker and am currently exploring its capabilities. Now I have a question regarding its use with PostgreSQL. I'm using containerized application servers behind a reverse proxy. My current setup has the PGSERVICE environment variable set for each application server, so that psycopg2 can connect to the PostgreSQL database using connection information from the pg_service.conf file. It allows me to avoid storing database credentials in application-related configuration files. Is there a way that Roundup Tracker can avoid using the default database settings and use the values from pg_service.conf to connect to the database? Thank you. -- With appreciation, Ivanov |
From: John P. R. <ro...@cs...> - 2023-10-19 14:35:53
|
Hi Norbert: In message <DU2PR01MB8557460D914280A05A9284D7E8D4A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >The Roundup REST API seems to be changed compared to v2.1.0 > >Code running well with 2.1.0 leads in 2.3.0 to this error during the "create issue" endpoint > >'http://tvmtmcsdebiansrv.myDomain.com:8917/issues/rest/data/issue/@poe' > >Header: > 'X-requested-with:' put: 'rest'; > 'Referer' put: 'http://tvmtmcsdebiansrv. myDomain.com:8917/issues/rest'; > >Erorr: >153, { "error": { "status": 400, "msg": "Required Header Missing" } } > >Which header is now needed for 2.3.0 ? Try adding the Origin header. It may be a side effect of: changeset: 7150:72a54826ff4f user: John Rouillard <ro...@ie...> date: Tue Feb 21 16:42:20 2023 -0500 files: roundup/cgi/client.py test/test_liveserver.py description: better rest Origin check; refactor CORS preflight code. A previous version allowed requests without an origin that should require it (e.g. an OPTIONS or PATCH request). Moved the origin checking logic into the main flow. It looks like this was limited to OPTIONS/PATCH requests as handle_csrf() (called later in the main flow) handles POST, PUT, DELETE verbs. Refactored CORS preflight request code into functions and call them from main flow. Also return immediately. Prior code processed the options request a second time due to falling through. Modified is_origin_header_ok to return True if origin was missing and it was a get request. Fixed tests that make OPTIONS requests to supply origin. The Origin should always have be required for POST etc. From your report plus one other I got off list, it appears that POST command origin checking wasn't correct in earlier versions either. I'll toss up an errata about it at: https://wiki.roundup-tracker.org/ReleaseErrata Also the Referer header looks broken, does your domain name have a space in it? Have a great day. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-19 09:34:18
|
Hello The Roundup REST API seems to be changed compared to v2.1.0 Code running well with 2.1.0 leads in 2.3.0 to this error during the "create issue" endpoint 'http://tvmtmcsdebiansrv.myDomain.com:8917/issues/rest/data/issue/@poe' Header: 'X-requested-with:' put: 'rest'; 'Referer' put: 'http://tvmtmcsdebiansrv. myDomain.com:8917/issues/rest'; Erorr: 153, { "error": { "status": 400, "msg": "Required Header Missing" } } Which header is now needed for 2.3.0 ? Thanks Norbert |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-18 13:55:55
|
Hi John Ok... seems to be an issue with this VM... will use a new one installed from scratch Thanks Norbert -----Ursprüngliche Nachricht----- Von: ro...@cs... <ro...@cs...> Gesendet: Mittwoch, 18. Oktober 2023 15:01 An: SCHLEMMER Norbert <Nor...@pd...> Cc: rou...@li... Betreff: Re: AW: AW: [Roundup-users] V2.3.0 Docker image (amd64) : Healthcheck *EXTERNAL source* Hi Norbert: In message <DU2PR01MB8557A42F2C7ABA6C35D5F45BE8D5A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >See my test results below > >~ $ ps -ef | grep roundup-server > 7 roundup 0:09 {roundup-server} /usr/local/bin/python /usr/local/bin/roundup-server -n 0.0.0.0 issues=tracker >20058 roundup 0:00 grep roundup-server > > >~ $ wget -q -O /dev/null --no-verbose http://localhost:8080/issues/ >wget: server returned error: HTTP/1.1 503 Service Unavailable >~ $ echo $? >1 While mine looks like: $ docker exec fleet-tracker ps -ef PID USER TIME COMMAND 1 roundup 0:00 /usr/bin/dumb-init ./roundup_start fleet=tracker 7 roundup 0:20 {roundup-server} /usr/local/bin/python /usr/local/bin/roundup-server -n 0.0.0.0 fleet=tracker $ docker exec fleet-tracker sh -c 'wget -q -O /dev/null --no-verbose http://localhost:8080/fleet/; echo $?' 0 I have no idea why/how you are getting a 503. In fact I can't find Roundup ever using/returning 503 or http.SERVICE_UNAVAILABLE anywhere in the Roundup code. So I claim the 503 is not coming from Roundup. I verified that the error from wget when connecting to the wrong port is different: wget: can't connect to remote host (127.0.0.1): Connection refused If it can't resolve the hostname, wget returns: wget: bad address 'loclhost:8080' Is there some other web server running on the system or inside the docker container that wget inside the container could be hitting? Can you try running docker with a -p of: -p 127.0.0.1:<external port>:8080 where external port is the first port number you are currently using. The docs recommends using 127.0.0.1 so that docker doesn't play games with the external firewall rules on your host. I tried running docker using just '-p <external port>:8080' and I can't reproduce your error. The heartbeat check works fine. So I am stumped as to why this is is erroring. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: John P. R. <ro...@cs...> - 2023-10-18 13:01:03
|
Hi Norbert: In message <DU2PR01MB8557A42F2C7ABA6C35D5F45BE8D5A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >See my test results below > >~ $ ps -ef | grep roundup-server > 7 roundup 0:09 {roundup-server} /usr/local/bin/python /usr/local/bin/roundup-server -n 0.0.0.0 issues=tracker >20058 roundup 0:00 grep roundup-server > > >~ $ wget -q -O /dev/null --no-verbose http://localhost:8080/issues/ >wget: server returned error: HTTP/1.1 503 Service Unavailable >~ $ echo $? >1 While mine looks like: $ docker exec fleet-tracker ps -ef PID USER TIME COMMAND 1 roundup 0:00 /usr/bin/dumb-init ./roundup_start fleet=tracker 7 roundup 0:20 {roundup-server} /usr/local/bin/python /usr/local/bin/roundup-server -n 0.0.0.0 fleet=tracker $ docker exec fleet-tracker sh -c 'wget -q -O /dev/null --no-verbose http://localhost:8080/fleet/; echo $?' 0 I have no idea why/how you are getting a 503. In fact I can't find Roundup ever using/returning 503 or http.SERVICE_UNAVAILABLE anywhere in the Roundup code. So I claim the 503 is not coming from Roundup. I verified that the error from wget when connecting to the wrong port is different: wget: can't connect to remote host (127.0.0.1): Connection refused If it can't resolve the hostname, wget returns: wget: bad address 'loclhost:8080' Is there some other web server running on the system or inside the docker container that wget inside the container could be hitting? Can you try running docker with a -p of: -p 127.0.0.1:<external port>:8080 where external port is the first port number you are currently using. The docs recommends using 127.0.0.1 so that docker doesn't play games with the external firewall rules on your host. I tried running docker using just '-p <external port>:8080' and I can't reproduce your error. The heartbeat check works fine. So I am stumped as to why this is is erroring. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-18 06:14:11
|
Hi John See my test results below Br Norbert ~ $ ps -ef | grep roundup-server 7 roundup 0:09 {roundup-server} /usr/local/bin/python /usr/local/bin/roundup-server -n 0.0.0.0 issues=tracker 20058 roundup 0:00 grep roundup-server ~ $ wget -q -O /dev/null --no-verbose http://localhost:8080/issues/ wget: server returned error: HTTP/1.1 503 Service Unavailable ~ $ echo $? 1 ~ $ wget -q -O /dev/null --no-verbose http://tvmtmcsdebiansrv.my.domain.com:8917/issues/ ~ $ echo $? 0 ~ $ |
From: John P. R. <ro...@cs...> - 2023-10-17 16:24:47
|
Hi Norbert: In message <DU2PR01MB8557CE54F0D16BC248E28C30E8D6A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >Now I got it running, image :multi on arm64 and with mariadb > >But the healthcheck is broken as before on amd64 I replied to your earlier report on this. Geting the ps -ef outout for roundup-tracker would be useful. Maybe this is an isue with a different character set or locale? >ps: which postgreSQL versions are supported? postgres:16-bookworm ? Will give that a try... I am running 15.3 in development. The docs claim anything 8.x or newer. So 16.x (bookworm) should work. >pi@hadersdorf:~/Roundup $ docker-compose down && docker-compose rm -f && docker-compose up -d [elided the output] That looks great. Is your docker compose much different from the one that is in the source tree? Thanks. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: John P. R. <ro...@cs...> - 2023-10-17 16:19:58
|
Hi Norbert: In message <DU2PR01MB8557078296A1DE50EA88F6BBE8D6A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >Sorry, please delete my email from "Dienstag, 17. Oktober 2023 09:49" Done. I am not sure how you got that traceback. It looks like you got into roundup-admin install mode without using the -it flag to docker run. I have code to detect when roundup_start is called with "shell" but is missing the docker '-it' flags. Demo mode should never become interactive. With admin mode, you can give non-interactive commands on the command line. So I don't check there either. >The image "roundup-development:multi" is up-and-running under >Raspberry OS 64 bit Cool. Do I need to update/clarify the docs? >Will do some tests and with mariadb too... Thanks -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: John P. R. <ro...@cs...> - 2023-10-17 16:05:48
|
In message <DU2PR01MB85579FEA05583DF60DD1E57AE8D6A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >~ $ sh -xv roundup_healthcheck >#! /bin/sh > ># if there are multiple trackers, d=demo t=tracker ... ># returns last one for testing that server is up. Does not test ># each tracker. >tracker=$(ps -ef | sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p') >+ ps -ef >+ sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p' >+ tracker='issues >issues' >wget -q -O /dev/null --no-verbose http://localhost:8080/${tracker:-demo}/ >+ wget -q -O /dev/null --no-verbose http://localhost:8080/issues issues/ ^^^^^^^^^^^^^ Hmm, the path /issues issues/ is wrong. It looks like the ps output is broken. I can't even craft input to that sed command that produces "issue issue". >wget: server returned error: HTTP/1.1 503 Service Unavailable That's odd as well I would expect a 404 not found. What does: ps -ef | grep roundup-server output? The last arguments to roundup-server should look like <tracker_name>=<relative_directory_path>. >~ $ wget -q -O /dev/null --no-verbose http://tvmtmcsdebiansrv.my.domain.com:8917/issues/ You didn't provide the exit status of the command (the $? variable), but the command isn't supposed to produce any output. It's run just for its exit status. So what you reported doesn't look wrong. You should be able to run: wget -q -O /dev/null --no-verbose http://localhost:8080/issues/ echo $? from inside the docker container (docker exec -it ....) as well and 'echo $?' should be 0. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-17 13:53:59
|
Hi John rounduptracker/roundup-development:multi running on amd64 with demo seems to be broken, service isn't starting br Norbert tmcs@tvmTmcsDebianSrv:~/Roundup-appliance/Roundup-2.3.0-Multi$ docker run --rm -p 8919:8080 --name roundup-230-multi -v $PWD:/usr/src/app/tracker rounduptracker/roundup-development:multi demo tmcs@tvmTmcsDebianSrv:~/Roundup-appliance/Roundup-2.3.0-Multi$ tmcs@tvmTmcsDebianSrv:~/Roundup-appliance/Roundup-2.3.0-Multi$ |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-17 13:34:20
|
Hi John Now I got it running, image :multi on arm64 and with mariadb But the healthcheck is broken as before on amd64 ps: which postgreSQL versions are supported? postgres:16-bookworm ? Will give that a try... Br Norbert pi@hadersdorf:~/Roundup $ docker-compose down && docker-compose rm -f && docker-compose up -d [+] Running 3/3 ✔ Container roundup-230 Removed 0.5s ✔ Container mariadb-230 Removed 4.8s ✔ Network roundup_default Removed 0.4s No stopped containers [+] Running 3/3 ✔ Network roundup_default Created 0.4s ✔ Container mariadb-230 Started 0.1s ✔ Container roundup-230 Started 0.1s pi@hadersdorf:~/Roundup $ docker-compose ps NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS mariadb-230 lscr.io/linuxserver/mariadb "/init" mariadb About a minute ago Up About a minute 3306/tcp roundup-230 rounduptracker/roundup-development:multi "/usr/bin/dumb-init ./roundup_start issues=tracker" roundup-app About a minute ago Up About a minute (health: starting) 0.0.0.0:8917->8080/tcp pi@hadersdorf:~/Roundup $ docker-compose ps NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS mariadb-230 lscr.io/linuxserver/mariadb "/init" mariadb About a minute ago Up About a minute 3306/tcp roundup-230 rounduptracker/roundup-development:multi "/usr/bin/dumb-init ./roundup_start issues=tracker" roundup-app About a minute ago Up About a minute (health: starting) 0.0.0.0:8917->8080/tcp pi@hadersdorf:~/Roundup $ docker-compose ps NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS mariadb-230 lscr.io/linuxserver/mariadb "/init" mariadb About a minute ago Up About a minute 3306/tcp roundup-230 rounduptracker/roundup-development:multi "/usr/bin/dumb-init ./roundup_start issues=tracker" roundup-app About a minute ago Up About a minute (health: starting) 0.0.0.0:8917->8080/tcp pi@hadersdorf:~/Roundup $ |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-17 12:52:22
|
Hi John Sorry, please delete my email from "Dienstag, 17. Oktober 2023 09:49" The image "roundup-development:multi" is up-and-running under Raspberry OS 64 bit Will do some tests and with mariadb too... Br Norbert docker run --rm -p 8918:8080 --name roundup-multi -v $PWD:/usr/src/app/tracker rounduptracker/roundup-development:multi demo If docker reports a bind error, you can set the Docker environment variable PORT_8080 to fix it. Add -e PORT_8080=port_number to the docker run command. The port_number must match the first value to -p which must be an unused port on your server. Restarting existing tracker. Demo Tracker Home: tracker/demo Server running - connect to: http://localhost:8917/demo/ 1. Log in as "demo"/"demo" or "admin"/"admin". 2. Hit Control-C to stop the server. 3. Re-start the server by running "/usr/local/bin/roundup-demo" again. 4. Reset the tracker by running "/usr/local/bin/roundup-demo nuke". By default the demo tracker is set up to be accessed from "localhost". If you want to run it on a server, edit "/usr/src/app/demo/config.ini" and set the "web" option in section "[tracker]" to your host name, then restart demo. If you want to change backend types, you must use "nuke". 127.0.0.1 - - [17/Oct/2023 12:47:47] "GET /demo/ HTTP/1.1" 200 - 192.168.10.6 - - [17/Oct/2023 12:47:53] "GET /demo/ HTTP/1.1" 200 - 192.168.10.6 - - [17/Oct/2023 12:47:54] "GET /demo/@@file/style.css HTTP/1.1" 200 - 192.168.10.6 - - [17/Oct/2023 12:47:54] "GET /favicon.ico HTTP/1.1" 200 - 127.0.0.1 - - [17/Oct/2023 12:48:17] "GET /demo/ HTTP/1.1" 200 - 127.0.0.1 - - [17/Oct/2023 12:48:47] "GET /demo/ HTTP/1.1" 200 - 192.168.10.6 - - [17/Oct/2023 12:48:54] Request timed out: TimeoutError('timed out') 127.0.0.1 - - [17/Oct/2023 12:49:18] "GET /demo/ HTTP/1.1" 200 - 127.0.0.1 - - [17/Oct/2023 12:49:48] "GET /demo/ HTTP/1.1" 200 - |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-17 12:37:44
|
Hi John Please find below the output as requested Br Norbert ~ $ sh -xv roundup_healthcheck #! /bin/sh # if there are multiple trackers, d=demo t=tracker ... # returns last one for testing that server is up. Does not test # each tracker. tracker=$(ps -ef | sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p') + ps -ef + sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p' + tracker='issues issues' wget -q -O /dev/null --no-verbose http://localhost:8080/${tracker:-demo}/ + wget -q -O /dev/null --no-verbose http://localhost:8080/issues issues/ wget: server returned error: HTTP/1.1 503 Service Unavailable ~ $ ~ $ ~ $ wget -q -O /dev/null --no-verbose http://tvmtmcsdebiansrv.my.domain.com:8917/issues/ ~ $ ~ $ -----Ursprüngliche Nachricht----- Von: ro...@cs... <ro...@cs...> Gesendet: Montag, 16. Oktober 2023 20:15 An: SCHLEMMER Norbert <Nor...@pd...> Cc: rou...@li... Betreff: Re: [Roundup-users] V2.3.0 Docker image (amd64) : Healthcheck *EXTERNAL source* Hello Norbert: In message <DU2PR01MB855781D2792A3B884054D2A4E8D7A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >Tested the Docker image under Debian and changed the web URL in >config.ini to the hostname of the VM. >After that the health check is broken, because of hardcoded URL in >script scripts/Docker/roundup_healthcheck Hmm, that's not expected. The heartbeat check uses the internal docker loopback intentionally to prevent the need to reach outside the container. >tracker=$(ps -ef | sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p') >wget -q -O /dev/null --no-verbose >http://localhost:8080/${tracker:-demo}/ The sed command parses the roundup-server command line and extracts the tracker name of the last tracker specified. Then it uses the tracker name to query localhost:8080 using http. That should work. It works with a tracker with an external web url I am running right now. The links on the returned page won't work as they embed the real web url not localhost:8080, but for heartbeat testing this should and does work for me. Can you: docker exec -it <container name> sh and run 'sh -xv roundup_healthcheck' and see what it looks like? The output from my check is: [...] + tracker=$(ps -ef | sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p') + ps -ef + sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p' + tracker=fleet wget -q -O /dev/null --no-verbose http://localhost:8080/${tracker:-demo}/ + wget -q -O /dev/null --no-verbose http://localhost:8080/fleet/ you should see something similar with the name of your tracker replacing fleet. >maybe there should be a environment parameter for health check like >HEALTHCHECK_URL=http://tvmtmcsdebiansrv.myDomain.com:8917/ The docker container (if running behind a proxy/ingress controller) may not have access to the external interface required to resolve/reach http://some.host.com/tracker. As a result I just connect on the internal docker loopback network. >Better the " [tracker] / web" parameter from config.ini can be used instead. Well there can be multiple trackers running, so which config.ini should be used? The heartbeat code only checks the last tracker configured, but this tells me if the server is hung at least. The heartbeat does provide a bit of check on database connectivity/availability if it shows an index screen. Have a great evening. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-17 07:49:19
|
Hi John Pulled latest image rounduptracker/roundup-development:multi Started the image as part of docker-compose (same as with rounduptracker/roundup under amd64) With this result: Installing issues tracker in tracker Templates:: jinja2, devel, minimal, classic, responsive Traceback (most recent call last): File "/usr/local/bin/roundup-admin", line 33, in <module> sys.exit(load_entry_point('roundup==2.3.0', 'console_scripts', 'roundup-admin')()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/roundup-2.3.0-py3.11.egg/roundup/scripts/roundup_admin.py", line 50, in run sys.exit(tool.main()) ^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/roundup-2.3.0-py3.11.egg/roundup/admin.py", line 2213, in main ret = self.run_command(args) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/roundup-2.3.0-py3.11.egg/roundup/admin.py", line 2067, in run_command return self.do_install(self.tracker_home, args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/roundup-2.3.0-py3.11.egg/roundup/admin.py", line 1213, in do_install template = self._get_choice( ^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/roundup-2.3.0-py3.11.egg/roundup/admin.py", line 419, in _get_choice argument = self.my_input('%s [%s]: ' % (prompt, default)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ EOFError: EOF when reading a line Select template [classic]: Exiting on pipefail Why is there a diff to rounduptracker/roundup ? Thanks Norbert |
From: John P. R. <ro...@cs...> - 2023-10-17 02:45:50
|
Hi Norbert In message <DU2PR01MB8557BA86651E5B5D42345CFEE8D7A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >But the same docker compose (but rounduptracker/roundup-development:multi) >doesn't work under arm64, the tracker will not be initialised. I am rebuilding the multi arch images now. There was a bug in the roundup_start script that caused demo to incorrectly exit. Please grab a new copy of rounduptracker/roundup-development:multi. demo mode should work now and not exit. I also added an error handler that will report when exiting due to an error. Have a great day, sorry for the bug. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: John P. R. <ro...@cs...> - 2023-10-16 18:15:02
|
Hello Norbert: In message <DU2PR01MB855781D2792A3B884054D2A4E8D7A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >Tested the Docker image under Debian and changed the web URL in >config.ini to the hostname of the VM. >After that the health check is broken, because of hardcoded URL >in script scripts/Docker/roundup_healthcheck Hmm, that's not expected. The heartbeat check uses the internal docker loopback intentionally to prevent the need to reach outside the container. >tracker=$(ps -ef | sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p') >wget -q -O /dev/null --no-verbose http://localhost:8080/${tracker:-demo}/ The sed command parses the roundup-server command line and extracts the tracker name of the last tracker specified. Then it uses the tracker name to query localhost:8080 using http. That should work. It works with a tracker with an external web url I am running right now. The links on the returned page won't work as they embed the real web url not localhost:8080, but for heartbeat testing this should and does work for me. Can you: docker exec -it <container name> sh and run 'sh -xv roundup_healthcheck' and see what it looks like? The output from my check is: [...] + tracker=$(ps -ef | sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p') + ps -ef + sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p' + tracker=fleet wget -q -O /dev/null --no-verbose http://localhost:8080/${tracker:-demo}/ + wget -q -O /dev/null --no-verbose http://localhost:8080/fleet/ you should see something similar with the name of your tracker replacing fleet. >maybe there should be a environment parameter for health check like >HEALTHCHECK_URL=http://tvmtmcsdebiansrv.myDomain.com:8917/ The docker container (if running behind a proxy/ingress controller) may not have access to the external interface required to resolve/reach http://some.host.com/tracker. As a result I just connect on the internal docker loopback network. >Better the " [tracker] / web" parameter from config.ini can be used instead. Well there can be multiple trackers running, so which config.ini should be used? The heartbeat code only checks the last tracker configured, but this tells me if the server is hung at least. The heartbeat does provide a bit of check on database connectivity/availability if it shows an index screen. Have a great evening. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: John P. R. <ro...@cs...> - 2023-10-16 17:51:00
|
Hi Norbert: In message <DU2PR01MB8557BA86651E5B5D42345CFEE8D7A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >Did a test with rounduptracker/roundup:latest under amd64 and with >mariadb and got it running. Used a docker compose script. > >After starting this container the mounted tracker directory will be >initialised. As a next step I changed config.ini, restarted and the >mariadb container was connected to the Roundup app. Importing from a >prev version works too. Nice. I assume you ran the demo mode first to initialize a tracker, then stopped the container, changed the config to use a mysql db and ran init? Did you try rounduptracker/roundup-development:multi on amd64? It shoud have support for that arch in it. If it fails then something may be wrong with the dockerfile or development Roundup. roundup:latest is supposed to be the 2.3 release, not the current development (which was used for multi). If multi amd64 succeeds, then the amd64 build may be broken in some odd way (e.g. the mariadb/mysql module wasn't available/built). But I seem to remember from one of your prior emails, that mysql was a db option. >But the same docker compose (but >rounduptracker/roundup-development:multi) doesn't work under arm64, >the tracker will not be initialised. When you say will not be initialized, do you mean manually running roundup-admin init after config.ini changes, or are you using the demo target? >For me there should be no difference between amd64 and arm64 during >the startup procedure I would agree. Do you see any errors when trying to initialize the tracker? Try using the multiarch for amd64 and see if that fails to initialize. Thanks. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-16 12:56:38
|
Hi John Did a test with rounduptracker/roundup:latest under amd64 and with mariadb and got it running. Used a docker compose script. After starting this container the mounted tracker directory will be initialised. As a next step I changed config.ini, restarted and the mariadb container was connected to the Roundup app. Importing from a prev version works too. But the same docker compose (but rounduptracker/roundup-development:multi) doesn't work under arm64, the tracker will not be initialised. For me there should be no difference between amd64 and arm64 during the startup procedure Br Norbert |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-16 11:29:08
|
Hello Team Tested the Docker image under Debian and changed the web URL in config.ini to the hostname of the VM. After that the health check is broken, because of hardcoded URL in script scripts/Docker/roundup_healthcheck tracker=$(ps -ef | sed -ne '/roundup-server/s/^.*\s\(\w*\)=.*$/\1/p') wget -q -O /dev/null --no-verbose http://localhost:8080/${tracker:-demo}/ maybe there should be a environment parameter for health check like HEALTHCHECK_URL=http://tvmtmcsdebiansrv.myDomain.com:8917/ Better the " [tracker] / web" parameter from config.ini can be used instaed. Regards Norbert |
From: John P. R. <ro...@cs...> - 2023-10-12 20:28:01
|
Hi Norbert: In message <DU2PR01MB855760E04293FEC9C16F27B1E8D3A@DU2PR01MB8557.eurprd01.prod. exchangelabs.com>, SCHLEMMER Norbert writes: >Please find below the output of my tests @RPi 4 >I don't know how to get the container running It looks like yu didn;t initilize the tracker properly. Also, the argument to run the server is incorrect. It should be something like "demo=tracker_home" (note tracker_home is just the simple subdirectory, in the app directory, not a full path). The final error you see is caused by parsing "tracker" expecting "demo=tracker_home". More comments inline. >Do you have a docker-compose.yml file ? >It would be fine to have a Roundup running with MariaDB as database container (linuxserver/mariadb) >or Postgresql / arm64v8/postgres:15-bookworm (?) There is the docker-compose you put together that is in the source distribution. But that's it. >pi@hadersdorf:~/Roundup $ docker run -it -p 127.0.0.1:8917:8080 --name roundup_demo -v $PWD:/usr/src/app/tracker rounduptracker/roundup-development:multi shell >~ $ ls -lrt >total 16 >-rwxr-xr-x 1 root root 291 Jul 19 03:12 roundup_healthcheck >-rwxr-xr-x 1 root root 5711 Sep 8 02:08 roundup_start >drwxr-xr-x 3 roundup roundup 4096 Oct 10 07:42 tracker >~ $ roundup-admin -i tracker install Ok so the docker image runs (you're at the shell prompt in the image). [elided normal install prompts etc.] > You MUST run the "roundup-admin initialise" command once you've performed > the above steps. >--------------------------------------------------------------------------- > >~ $ > >Following options need adjustments: ># [tracker]: web ># [mail]: domain, host > >Modfied config.ini with: >web = http://hadersdorf.xxx.at:8917/demo You are missing the trailing /. >domain = xxx.at >host = mail.xxx.at Is the command below still inside the docker shell command? >~ $ roundup-admin initialise >Enter tracker home: tracker >Admin Password: > Confirm: >Error: Invalid value for TRACKER_WEB: 'http://hadersdorf.sieben.neunzehn.at:8917/demo' >Value must end with /. Your config file has the wrong value, so the tracker isn't initialized. >~ $ exit I assume this exits the docker container. Note you still haven't completed the initialization of the tracker. >docker rm -f roundup_demo > >pi@hadersdorf:~/Roundup $ docker rm -f roundup_demo >roundup_demo I'm not sure what roundup_demo is. >pi@hadersdorf:~/Roundup $ docker run -it -p 127.0.0.1:8917:8080 --name roundup_demo -v $PWD:/usr/src/app/tracker rounduptracker/roundup-development:multi tracker >Traceback (most recent call last): > File "/usr/local/lib/python3.11/site-packages/roundup-2.3.0-py3.11.egg/roundup/scripts/roundup_server.py", line 1109, in run > name, home = arg.split('=') > ^^^^^^^^^^ >ValueError: not enough values to unpack (expected 2, got 1) > >During handling of the above exception, another exception occurred: > >Traceback (most recent call last): > File "/usr/local/bin/roundup-server", line 33, in <module> > sys.exit(load_entry_point('roundup==2.3.0', 'console_scripts', 'roundup-server')()) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/local/lib/python3.11/site-packages/roundup-2.3.0-py3.11.egg/roundup/scripts/roundup_server.py", line 1111, in run > raise ValueError(_("Instances must be name=home")) >ValueError: Instances must be name=home The final argument (tracker) is incorrect you probably want something like demo=demo (assuming there is an initialized tracker in $PWD/demo. So it looks like you need to fix the web seting, finish the initialization and supply the correct tracker=directory argumnent. Let me know how that goes. If that works, I claim docker run -it -p 127.0.0.1:8917:8080 --name roundup_demo -v $PWD:/usr/src/app/tracker rounduptracker/roundup-development:multi demo should have worked to spin up a tracker on http://localhost:8917/demo/. So I would be interestined in what's happening in the demo case. Have a great weekend. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. |
From: SCHLEMMER N. <Nor...@pd...> - 2023-10-12 20:02:16
|
Hi John Please find below the output of my tests @RPi 4 I don't know how to get the container running Do you have a docker-compose.yml file ? It would be fine to have a Roundup running with MariaDB as database container (linuxserver/mariadb) or Postgresql / arm64v8/postgres:15-bookworm (?) Br Norbert pi@hadersdorf:~/Roundup $ docker run -it -p 127.0.0.1:8917:8080 --name roundup_demo -v $PWD:/usr/src/app/tracker rounduptracker/roundup-development:multi shell ~ $ ls -lrt total 16 -rwxr-xr-x 1 root root 291 Jul 19 03:12 roundup_healthcheck -rwxr-xr-x 1 root root 5711 Sep 8 02:08 roundup_start drwxr-xr-x 3 roundup roundup 4096 Oct 10 07:42 tracker ~ $ roundup-admin -i tracker install Templates:: jinja2, devel, minimal, classic, responsive Select template [classic]: Back ends:: anydbm, mysql, sqlite, postgresql Select backend [anydbm]: sqlite --------------------------------------------------------------------------- You should now edit the tracker configuration file: /usr/src/app/tracker/config.ini ... at a minimum, you must set following options: [tracker]: web [mail]: domain, host If you wish to modify the database schema, you should also edit the schema file: /usr/src/app/tracker/schema.py You may also change the database initialisation file: /usr/src/app/tracker/initial_data.py ... see the documentation on customizing for more information. You MUST run the "roundup-admin initialise" command once you've performed the above steps. --------------------------------------------------------------------------- ~ $ Following options need adjustments: # [tracker]: web # [mail]: domain, host Modfied config.ini with: web = http://hadersdorf.xxx.at:8917/demo domain = xxx.at host = mail.xxx.at ~ $ roundup-admin initialise Enter tracker home: tracker Admin Password: Confirm: Error: Invalid value for TRACKER_WEB: 'http://hadersdorf.sieben.neunzehn.at:8917/demo' Value must end with /. Usage: initialise [adminpw] Initialise a new Roundup tracker. The administrator details will be set at this step. Execute the tracker's initialisation function dbinit.init() ~ $ exit docker rm -f roundup_demo pi@hadersdorf:~/Roundup $ docker rm -f roundup_demo roundup_demo pi@hadersdorf:~/Roundup $ docker run -it -p 127.0.0.1:8917:8080 --name roundup_demo -v $PWD:/usr/src/app/tracker rounduptracker/roundup-development:multi tracker Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/roundup-2.3.0-py3.11.egg/roundup/scripts/roundup_server.py", line 1109, in run name, home = arg.split('=') ^^^^^^^^^^ ValueError: not enough values to unpack (expected 2, got 1) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/local/bin/roundup-server", line 33, in <module> sys.exit(load_entry_point('roundup==2.3.0', 'console_scripts', 'roundup-server')()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/roundup-2.3.0-py3.11.egg/roundup/scripts/roundup_server.py", line 1111, in run raise ValueError(_("Instances must be name=home")) ValueError: Instances must be name=home |
From: Tonu M. <tm...@um...> - 2023-10-10 16:10:33
|
The addition of the detector worked perfectly. Thank you! On Tue, Oct 10, 2023 at 10:42 AM John P. Rouillard <ro...@cs...> wrote: > Hello Tonu: > > In message <CABDFm8gEASbHiyE1dEe3xfVnD= > T_8...@ma...> > , > Tonu Mikk via Roundup-users writes: > >I would like to configure my tracker to email me every time a new issue is > >created. I added my email address to the dispatcher line in the config.ini > >file, but that didn't work. I know it is documented and I searched, but I > >couldn't find the solution. > > I shared your expectation about dispatcher. Then I looked into it and > searched the code. The key part of the dispatcher is: > > # The 'dispatcher' is a role that can get notified > # of new items to the database. > # It is used by the ERROR_MESSAGES_TO config setting. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > the same wording shows up in reference.txt (formerly part of > customizing.txt). > > In doc/whatsnew-0.7.txt > > A new config option has been added that specifies the email address of > a "dispatcher" role. This email address acts as a central sentinel for > issues coming into the system. You can configure it so that all e-mail > error messages get bounced to them, them and the user in question, or > just the user (default). > > which explains it a little better, but still confusing. "issue" in > this case is not an issue as in 'an issue tracked by Roundup'. Instead > issue here means an issue/failure in email delivery or other bounce > message. > > Indeed the only reference in the code to this setting is in > bounce_message() in mailer.py. > > I'll see what I can do to clarify the wording on that. > > None of this solves your "issue" (hmm, irony...). > > However there is a "newissuecopy" reactor provided in the source tree > in the detectors directory. It can also be retrieved from source > control at: > > > https://sourceforge.net/p/roundup/code/ci/default/tree/detectors/newissuecopy.py > > It should be as easy as putting the file in the detectors directory of > your tracker's home directory. Then change "team@team.host" to your > address. Finally restart the tracker. > > It looks like the file works under both python 2 and 3, so you should > be good. > > Have a great day. > > -- > -- rouilj > John Rouillard > =========================================================================== > My employers don't acknowledge my existence much less my opinions. > -- Tonu Mikk Developer | Disability Resource Center | disability.umn.edu University of Minnesota | umn.edu tm...@um... Pronouns: He/Him |