Hi,
As the mythtv-status author, my preferred solution is to have mythtv-
status run via update-motd.
Just symlink'ing /usr/bin/mythtv-status into /etc/update-motd.d/ isn't
the best solution - you won't pick up the configuration settings.
However, the next version of mythtv-status will use a sta
But what happens if you don't have a frontend on the box? What happens
if the .mythtv/config.xml still doesn't exist?
My preference is use a modified MythTV.pm which doesn't require
accessing the database. I've made the modification, I just need to
submit the patch to the MythTV trac instance.
The status code that is being added to the init.d script is somewhat
misleading. mythtv-status doesn't actually have a daemon to run...
--
mythtv-status init script lacks the 'status' action
https://bugs.launchpad.net/bugs/251330
You received this bug notification because you are a member of Ubu
After a bit more consideration the status could report if the motd has
been updated in the past x minutes if the ENABLE flag is set.
Would this be inline with the Ubuntu policy?
--
mythtv-status init script lacks the 'status' action
https://bugs.launchpad.net/bugs/251330
You received this bug no
mythtv-status could run as the mythtv daemon user, but does the mythtv
daemon user have the config.xml file? (I'm not running 0.21 yet, so
can't check).
As Björn points out you can't just have the cron job run the init script
as the mythtv user due to needing to write to /etc/motd, but the init
s
If mythtv-status can find the backend using UPnP then this is a bug with
MythTV.pm (in the libmyth-perl package). That is where this warning
message is coming from.
--
the mythtv status cron script sends an annoying email every hour.
https://bugs.launchpad.net/bugs/311532
You received this bug n
I say warning message, in the MythTV.pm code there is a comment above
the line that emits the message that states "alert the user" - does the
user actually care in this case? I think not. :)
--
the mythtv status cron script sends an annoying email every hour.
https://bugs.launchpad.net/bugs/311
Hi,
Yes, I agree that on Jaunty this is the right way to solve this issue.
I'm also quite keen to port update-motd to Debian so I can resolve this
issue (although it hasn't been reported on Debian) there.
Cheers!
--
mythtv-status clobbers other motd update scripts
https://bugs.launchpad.net/bug
Public bug reported:
Binary package hint: libmyth-perl
Currently whenever MythTV.pm falls back to using UPnP it prints a message
to STDERR stating this fact. This is totally unrequired and annoys users.
The attached patch stops this behaviour.
This bug has been reported to MythTV -
http://s
** Attachment added:
"0001-Don-t-print-a-message-to-STDERR-if-we-re-using-UPnP.patch"
http://launchpadlibrarian.net/22425354/0001-Don-t-print-a-message-to-STDERR-if-we-re-using-UPnP.patch
--
MythTV.pm prints message in STDERR if UPnP is used
https://bugs.launchpad.net/bugs/327406
You receiv
*** This bug is a duplicate of bug 327406 ***
https://bugs.launchpad.net/bugs/327406
Public bug reported:
Binary package hint: libmyth-perl
Currently whenever MythTV.pm falls back to using UPnP it prints a message
to STDERR stating this fact. This is totally unrequired and annoys users.
I've submitted a patch for libmyth-perl which resolves this issue
#327406.
--
the mythtv status cron script sends an annoying email every hour.
https://bugs.launchpad.net/bugs/311532
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ub
Public bug reported:
Binary package hint: libmyth-perl
The Perl module is called MythTV.pm, to be consistent with other
packages the Ubuntu package should be called libmythtv-perl.
** Affects: mythtv (Ubuntu)
Importance: Undecided
Status: New
--
libmyth-perl package should be cal
Hi Dave,
Given the number of users of mythtv-status that have asked me about the
output I'd say the answer is "absolutely not".
This is a debugging message, it shouldn't be displayed to the users.
They don't care if UPnP has been used as long as they receive the
correct response.
Cheers!
--
My
Public bug reported:
To be able to build the libxmlbeans-java package you must have the
libxmlbeans-java package installed.
BUILD FAILED
/usr/src/eucalyptus/xmlbeans-2.4.0/build.xml:239: Warning: Could not find file
/usr/share/java/xmlbeans.jar to copy.
And there is a build-dep on itself. Huh?
Public bug reported:
Binary package hint: mythtv-status
The version upstream (and in Debian) is up to 0.7.1, which adds more
functionality, better handling of bogus data and more error checking.
Please consider this a wishlist bug.
** Affects: mythtv-status (Ubuntu)
Importance: Undecided
To reproduce this behaviour I expect you could create a DB user (using
createuser) that has none of these rights, then try and create a new
Glom DB using that user.
Cheers!
--
Andrew Ruthven
Wellington, New Zealand
At home: [EMAIL PROTECTED] | This space intentionally
esults, so I want to double
check them.
My wife is almost due with our first child, so my spare time is
reducing. But I'll try and get these instructions through to you soon.
Cheers!
--
Andrew Ruthven, Wellington, New Zealand
At home: [EMAIL PROTECTED] | This space in
Public bug reported:
Binary package hint: glom
Package: glom
Version: 1.3.8-0ubuntu1
Severity: normal
If the DB user you use to connect to PostgreSQL is missing required
access rights then Glom has some serious issues...
If createdb is missing then Glom fails to create the database (obviously)
Public bug reported:
Binary package hint: glom
Package: glom
Version: 1.3.8-0ubuntu1
Severity: normal
Glom suggests postgresql-8.2 which listens on port 5434 by default.
When Glom attempts to connect to the PostgreSQL database it tries
ports 5432 and 5433, but *not* 5434.
Unfortunately I don't
please, though you might
> want to wait for yet another version because the Ubuntu Glom maintainer
> is making some useful changes at the moment.
Okay, I'll give it a go when glom 1.3.9 appears in Feisty.
Thanks!
--
Andrew Ruthven, Wellington, New Zealand
At ho
Grizzly: That sounds like a different issue, could you please raise a
new bug report?
Ken: What verions is installed? (Run: dpkg -l mythtv-status )
--
Fails to find Disk information on .22
https://bugs.launchpad.net/bugs/455542
You received this bug notification because you are a member of Ubun
The only issue is that Ubuntu how has a different way of updating the
MOTD than in Debian.
--
Fails to find Disk information on .22
https://bugs.launchpad.net/bugs/455542
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs ma
Thank you, this is fixed in the upcoming 0.9.2 release of mythtv-status.
** Changed in: mythtv-status (Ubuntu)
Status: New => Fix Committed
** Changed in: mythtv-status (Ubuntu)
Assignee: (unassigned) => Andrew Ruthven (andrew-etc)
--
mythtv-status script incorrectly attem
I pondered more on this issue this morning and decided to allow the
service to fail to start on installation and remove. This is now fixed
in 1.0.1-6.
** Changed in: mythtv-status (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bu
Hmm... I'm interested in hearing opinions here on how better to handle
this situation.
mythtv-status was unable to collect information from the mythtv-backend,
so it was a legitimate failure.
Should I be asking for the hostname to check during installation?
Treat failure as acceptable? (Which mi
Ugh.
This evening I prepared a new package for Debian (1.0.1-2) which includes a
patch for this:
http://git.etc.gen.nz/cgi-bin/gitweb.cgi?p=mythtv-status.git;a=commit;h=089616c32247d109dc735da56838a6a4bc5d12f8
I'll be releasing version 1.0.2 which will also include this soon.
--
You received t
This issue is resolved in 0.10.4 in Debian Unstable...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1096252
Title:
Should display local times
To manage notifications about this bug go to:
https://
Yes, I have a fixed version for this. I haven't released yet because
I've been trying to resolve an issue with mythtv-status hanging around
waiting to hear back from the MythTV backend.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
We're still seeing the same issue on Ubuntu Trusty running the linux-
image-3.19.0-30-generic kernel.
Looking at this thread[0] on the Docker site which is referenced to in
the kernel bugzilla for this issue, there is a reference[1] to a
patch[2] on the netdev mailing list from 2015-11-05 by Franc
Public bug reported:
fai-do-scripts has a case statement to determine if a script under the
scripts directory should be read, and if it should, which log file to
save the output to.
It runs file -b on each file to determine the type of file, and then
runs the case statement. The output of file -b
This is now fixed in git. I'll push out a new release shortly.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1096252
Title:
Should display local times
To manage notifications about this bug go to:
Thanks Jan.
Sadly the Date::Manip stuff doesn't listen to locale for the date
format, you must explicitly set US or non-US when you init it.
To avoid that silliness I've changed it to use %Y-%m-%d which is
hopefully more generally acceptable.
I've also added another patch that handles the Ends t
Could someone please provide me the output of
http://localhost:6544/Status/GetStatusHTML (either ysuse lynx -dump or
wget) and I'll see if I can fix up the date logic in mythtv-status
rather than using a hack.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Thanks Ben, Ah ha that's the HTML version, how about
http://localhost:6544/Status/GetStatus ? That is what mythtv-status
will attempt to fetch as it is XML.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bu
Ah, I just clicked what comment #4 is about. The Data format issue in
#10 does not affect the real mythtv-status.
Better temporary solution:
edit mythtv-status, search for "http://"; and change "xml" on that line
to "/Status/GetStatus".
But I'll push out 0.10.2-2 shortly that is a much better f
Ah, that'll happen in /var/run/motd.orig doesn't exist for some reason.
That shouldn't cause the stop command to fail. I'll ignore failure
there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/596768
T
My recommendation would be to use the latest version of mythtv-status
which supports MythTV 0.25.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/945582
Title:
MythTV Status doesn't work with MythTV 0
Hi, 0.10.2-2 has been released and uploaded to Debian Unstable. I'm not
sure when it'll trickle through to Ubuntu.
You can also fetch it from own repo, add this to an apt sources file:
deb http://debian.etc.gen.nz sid main
(See http://www.etc.gen.nz/projects/mythtv/mythtv-status.html for more
de
I've release version 1.10.1 of mythtv-status (also in Debian Sid) that
adds support for MythTV 0.25.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/945582
Title:
MythTV Status doesn't work with MythT
Ah, I'm looking into the best way to resolve this now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1096252
Title:
Should display local times
To manage notifications about this bug go to:
https://
I'm hitting this issue on some new server hardware when trying to use
lspci from pciutils with a 16.04 installation. I'm wondering of there
has there been any progress on getting this fix released for Xenial?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Public bug reported:
On installation of cron on a new system, or (I expect) an upgrade with
no user crontab files the following is printed:
Setting up cron (3.0pl1-128.1ubuntu1.1) ...
stat: cannot stat '*': No such file or directory
stat: cannot stat '*': No such file or directory
stat: cannot st
43 matches
Mail list logo
