Bug#893369: systemd-udevd is killed at startup
Ah yes. I'm not sure you'll get much more from my system and logs now, can I install systemd:amd64 back now ? 2018-03-21 16:08 GMT+01:00 Michael Biebl : > Am 19.03.2018 um 16:36 schrieb LEDUQUE Mickaël: > > Start-Date: 2018-03-15 09:28:21 > > Commandline: apt dist-upgrade > > [..] > > > Remove: bundler:amd64 (1.15.1-1), systemd:amd64 (237-4), > > ruby-bundler:amd64 (1.15.1-1) > > End-Date: 2018-03-15 09:28:29 > > > > Also it seems at some point I had systemd:amd64 237-4 and many other > > packages as 238-2. > > Strangely I find no mention of removing system:amd64 even though > > See above: Remove: ... systemd:amd64 (237-4) > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#893369: systemd-udevd is killed at startup
Is it possible it could be because I put a package (I think it was a systemd package) on hold because apt warned me about a critical bug on systemd or udev about one week ago ? 2018-03-19 9:51 GMT+01:00 LEDUQUE Mickaël : > You're right, but honestly, I have no idea how this happened : > > $ dpkg -l systemd > Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder > | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/ > H=semi-installé/W=attend-traitement-déclenchements > |/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais) > ||/ Nom > Version Architecture > Description > +++- > =-=- > =-== > > = > ii systemd:i386 > 238-2 i386 > system and service manager > > > 2018-03-18 23:20 GMT+01:00 Michael Biebl : > >> Am 18.03.2018 um 22:41 schrieb LEDUQUE Mickaël: >> > No I don't think I have one >> > dpkg -l udev only shows udev and64 >> >> what about systemd? i386 or amd64 >> >> >> -- >> Why is it that all of the instruments seeking intelligent life in the >> universe are pointed away from Earth? >> >> >
Bug#893369: systemd-udevd is killed at startup
You're right, but honestly, I have no idea how this happened : $ dpkg -l systemd Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements |/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais) ||/ Nom Version Architecture Description +++-=-=-=-=== ii systemd:i386 238-2 i386 system and service manager 2018-03-18 23:20 GMT+01:00 Michael Biebl : > Am 18.03.2018 um 22:41 schrieb LEDUQUE Mickaël: > > No I don't think I have one > > dpkg -l udev only shows udev and64 > > what about systemd? i386 or amd64 > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#893369: systemd-udevd is killed at startup
No I don't think I have one dpkg -l udev only shows udev and64 2018-03-18 22:39 GMT+01:00 Michael Biebl : > Am 18.03.2018 um 22:33 schrieb LEDUQUE Mickaël: > > Looks like commenting out > > > > SystemCallArchitectures=native > > > > fixes the issue. > > Does that mean you have a udev:i386 installed on a amd64 system? > > > > If so, that would basically be a duplicate of #869719 > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#893369: systemd-udevd is killed at startup
Looks like commenting out SystemCallArchitectures=native fixes the issue. 2018-03-18 22:27 GMT+01:00 LEDUQUE Mickaël : > I disabled them all and got a normal startup. > Now I'll try to find the one (or more) that causes the problem. > Thanks. > > 2018-03-18 21:48 GMT+01:00 Michael Biebl : > >> Am 18.03.2018 um 20:38 schrieb Mickaël Leduque: >> > Package: systemd >> > Version: 238-2 >> > Followup-For: Bug #893369 >> > >> > It didn't work so I just added the options in /etc/default/grub. >> > Here are the journal and the systemctl list-jobs output (which is just >> "no jobs"). >> > >> >> Ok, thanks. >> Once you are dropped into the rescue shell, can you try running >> systemd-udevd manually, via >> /lib/systemd/systemd-udevd >> >> If that works, you can try disabling the security features in >> /lib/systemd/system/systemd-udevd.service >> by commenting out the lines >> >> MemoryDenyWriteExecute=yes >> RestrictRealtime=yes >> RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 >> SystemCallArchitectures=native >> LockPersonality=yes >> >> one by one and test if that makes a difference. >> >> >> -- >> Why is it that all of the instruments seeking intelligent life in the >> universe are pointed away from Earth? >> >> >
Bug#893369: systemd-udevd is killed at startup
I disabled them all and got a normal startup. Now I'll try to find the one (or more) that causes the problem. Thanks. 2018-03-18 21:48 GMT+01:00 Michael Biebl : > Am 18.03.2018 um 20:38 schrieb Mickaël Leduque: > > Package: systemd > > Version: 238-2 > > Followup-For: Bug #893369 > > > > It didn't work so I just added the options in /etc/default/grub. > > Here are the journal and the systemctl list-jobs output (which is just > "no jobs"). > > > > Ok, thanks. > Once you are dropped into the rescue shell, can you try running > systemd-udevd manually, via > /lib/systemd/systemd-udevd > > If that works, you can try disabling the security features in > /lib/systemd/system/systemd-udevd.service > by commenting out the lines > > MemoryDenyWriteExecute=yes > RestrictRealtime=yes > RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 > SystemCallArchitectures=native > LockPersonality=yes > > one by one and test if that makes a difference. > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#893369: systemd-udevd is killed at startup
Ok, I was more searching for a way to do it from inside grub itself, but this will have to do. 2018-03-18 18:55 GMT+01:00 Michael Biebl : > Am 18.03.2018 um 18:50 schrieb LEDUQUE Mickaël: > > I'll do all that, thanks. Do you know how I can set a correct keymap in > > the grub "e" text editor ? > > I don't. But this is literally the first google hit regarding that question > https://askubuntu.com/questions/751259/how-to- > change-grub-command-line-grub-shell-keyboard-layout > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#893369: systemd-udevd is killed at startup
I'll do all that, thanks. Do you know how I can set a correct keymap in the grub "e" text editor ? 2018-03-18 16:57 GMT+01:00 Michael Biebl : > On Sun, 18 Mar 2018 12:14:41 +0100 =?utf-8?q?Micka=C3=ABl_Leduque?= > wrote: > > Package: systemd > > Version: 238-2 > > Severity: critical > > Justification: breaks the whole system > > > > Dear Maintainer, > > > > After an update and a restart of the system, boot fails. It enters a > loop, where (apparently) systemd-udevd fails to start and is retries for a > certain time. > > After thaat, I am dropped into recovery mode (or failsafe, I don't > remember the word). > > I tried investigating the logs, but I couldn't go very far, I just saw > something that may (or may nt) be related, seccomp logs about systemd-udevd > using a syscall > > but that's an "audit" log so I'm not sure it does anyhting at all. > > See https://freedesktop.org/wiki/Software/systemd/Debugging/ > "If You Can Get a Shell", and attach the journalctl output of such a boot. > Since this affects udev, please also consider adding > udev.log_priority=debug to the kernel command line (see man > kernel-command-line) > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > >
Bug#820533: appstream: Icons 64x64 is refetched in full on every change
Icons are really big (6M, unacceptable), but metadata itself is not bad: 1.7M. While waiting for this issue to be fixed, I'd like to disable automatic download of these data, how do i do that ?
Bug#764705: [Pkg-postgresql-public] Bug#764705: Bug#764705: Bug#764705: Bug#764705: Bug#764705: Bug#764705: postgresql-9.4: ERROR: The database format changed between beta 2 and 3. Please dump, but ho
Ok, I have two versions of postgres installed and I don't know (remember) why. As I have nothing on the 9.4 one I don't have to care about the update. That's a bit of a relief. Sorry for the noise. Mickaël 2014-10-14 21:11 GMT+02:00 LEDUQUE Mickaël : > Should I have a result like this one ? > > Ver Cluster Port Status OwnerData directory Log file > 9.3 main5432 down postgres /var/lib/postgresql/9.3/main > /var/log/postgresql/postgresql-9.3-main.log > 9.4 main5433 down postgres /var/lib/postgresql/9.4/main > /var/log/postgresql/postgresql-9.4-main.log > > 2014-10-14 20:07 GMT+02:00 Christoph Berg : >> Re: LEDUQUE Mickaël 2014-10-14 >> >>> > The on-disk format of the PostgreSQL 9.4 data files has changed between >>> > beta2 and beta3 (and as a consequence, the catalog version number). For >>> > that >>> > reason, existing PostgreSQL 9.4 clusters need to be dumped using the old >>> > package version, and reloaded after upgrading the packages. >>> > >>> > The postgresql-9.4 package will refuse to upgrade if any version 9.4 >>> > clusters exist on the system. >>> > >>> > To resolve the situation, before upgrading, execute: >>> > # su - postgres >>> > $ pg_lsclusters >>> > $ pg_ctlcluster 9.4 main start >>> > $ pg_dumpall --cluster 9.4/main | gzip > 9.4-main.dump.gz >>> > $ cp -a /etc/postgresql/9.4/main 9.4-main.config >>> > $ pg_dropcluster 9.4 main --stop >>> > >>> > Then after the upgrade, execute: >>> > # su - postgres >>> > $ pg_createcluster 9.4 main >>> > $ cp 9.4-main.config/* /etc/postgresql/9.4/main >>> > $ pg_ctlcluster 9.4 main start >>> > $ zcat 9.4-main.dump.gz | psql -q >>> > $ rm -rf 9.4-main.config 9.4-main.dump.gz >>> > >>> > If you have other clusters besides the default "main", repeat the above >>> > steps appropriately. >>> >>> Hi, >>> >>> Maybe what's missing is a way to find if one has 'other clusters >>> besides the default "main"'. >> >> That's why I put the pg_lsclusters call in there. But I guess people >> who have other clusters would know (it's not like the cluster could >> have been there for a decade and then been forgotten). >> >> I'll update the last paragraph to be more explicit about that part. >> >> Christoph >> -- >> c...@df7cb.de | http://www.df7cb.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764705: [Pkg-postgresql-public] Bug#764705: Bug#764705: Bug#764705: Bug#764705: Bug#764705: Bug#764705: postgresql-9.4: ERROR: The database format changed between beta 2 and 3. Please dump, but ho
Should I have a result like this one ? Ver Cluster Port Status OwnerData directory Log file 9.3 main5432 down postgres /var/lib/postgresql/9.3/main /var/log/postgresql/postgresql-9.3-main.log 9.4 main5433 down postgres /var/lib/postgresql/9.4/main /var/log/postgresql/postgresql-9.4-main.log 2014-10-14 20:07 GMT+02:00 Christoph Berg : > Re: LEDUQUE Mickaël 2014-10-14 > >> > The on-disk format of the PostgreSQL 9.4 data files has changed between >> > beta2 and beta3 (and as a consequence, the catalog version number). For >> > that >> > reason, existing PostgreSQL 9.4 clusters need to be dumped using the old >> > package version, and reloaded after upgrading the packages. >> > >> > The postgresql-9.4 package will refuse to upgrade if any version 9.4 >> > clusters exist on the system. >> > >> > To resolve the situation, before upgrading, execute: >> > # su - postgres >> > $ pg_lsclusters >> > $ pg_ctlcluster 9.4 main start >> > $ pg_dumpall --cluster 9.4/main | gzip > 9.4-main.dump.gz >> > $ cp -a /etc/postgresql/9.4/main 9.4-main.config >> > $ pg_dropcluster 9.4 main --stop >> > >> > Then after the upgrade, execute: >> > # su - postgres >> > $ pg_createcluster 9.4 main >> > $ cp 9.4-main.config/* /etc/postgresql/9.4/main >> > $ pg_ctlcluster 9.4 main start >> > $ zcat 9.4-main.dump.gz | psql -q >> > $ rm -rf 9.4-main.config 9.4-main.dump.gz >> > >> > If you have other clusters besides the default "main", repeat the above >> > steps appropriately. >> >> Hi, >> >> Maybe what's missing is a way to find if one has 'other clusters >> besides the default "main"'. > > That's why I put the pg_lsclusters call in there. But I guess people > who have other clusters would know (it's not like the cluster could > have been there for a decade and then been forgotten). > > I'll update the last paragraph to be more explicit about that part. > > Christoph > -- > c...@df7cb.de | http://www.df7cb.de/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764705: [Pkg-postgresql-public] Bug#764705: Bug#764705: Bug#764705: Bug#764705: Bug#764705: postgresql-9.4: ERROR: The database format changed between beta 2 and 3. Please dump, but how?
> The on-disk format of the PostgreSQL 9.4 data files has changed between > beta2 and beta3 (and as a consequence, the catalog version number). For that > reason, existing PostgreSQL 9.4 clusters need to be dumped using the old > package version, and reloaded after upgrading the packages. > > The postgresql-9.4 package will refuse to upgrade if any version 9.4 > clusters exist on the system. > > To resolve the situation, before upgrading, execute: > # su - postgres > $ pg_lsclusters > $ pg_ctlcluster 9.4 main start > $ pg_dumpall --cluster 9.4/main | gzip > 9.4-main.dump.gz > $ cp -a /etc/postgresql/9.4/main 9.4-main.config > $ pg_dropcluster 9.4 main --stop > > Then after the upgrade, execute: > # su - postgres > $ pg_createcluster 9.4 main > $ cp 9.4-main.config/* /etc/postgresql/9.4/main > $ pg_ctlcluster 9.4 main start > $ zcat 9.4-main.dump.gz | psql -q > $ rm -rf 9.4-main.config 9.4-main.dump.gz > > If you have other clusters besides the default "main", repeat the above > steps appropriately. Hi, Maybe what's missing is a way to find if one has 'other clusters besides the default "main"'. Mickaël -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756895: Ugrade 1.13 -> 1.14 fails
On Sun, 3 Aug 2014 15:19:11 +0100 Edward Betts wrote: > The subject says 1.13 -> 1.14, but 1.14 isn't in Debian. > > I had exactly the same error (Duplicate column name 'width') when I did the 1.12->1.13 update. I had to remove the column and replay the update (I think I had to also do changes to the tt-rss config) to finish the update. BTW, I was also the one who reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724292 I seem to fail each update... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724292: tt-rss: Database update failed when going from 1.9 to 1.10
OK, I fixed it on my side by manually dropping the problematic column and re-upgrading the package. So as far as I'm concerned, all's right. As for why it happened to me (twice even !) IDK, but I may have a pattern. Each time, during database upgrade, when asked for the mysql root password, I misunderstood and gave the mysql tt-rss password, then when asked again, gave the good one. I don't see how that could cause this problem, but I can't think of anything else. Mickaël 2014-05-07 12:44 GMT+02:00 LEDUQUE Mickaël : > Ah I was hit by a breaking change in nginx (5.5.12+dfsg-1), permission > changes. It's not related to tt-rss. I'll tell you if tt-rss is still > broken so you can close. > > 2014-05-07 11:25 GMT+02:00 LEDUQUE Mickaël : >> Would you know where I can find the logs ? I don't find anything >> except this "502". >> >> 2014-05-07 10:46 GMT+02:00 LEDUQUE Mickaël : >>> First attempt to solve it on my side, I tried to answer "abandon" then >>> downgrade to 1.11. >>> Now I get HTTP 502 (bad gateway, it's served by nginx) on every request. >>> >>> 2014-05-07 1:39 GMT+02:00 Sebastian Reichel : >>>> On Tue, May 06, 2014 at 11:37:40PM +0200, LEDUQUE Mickaël wrote: >>>>> Hi, >>>>> I'm the same person that reported this bug. >>>>> I never had your last answer, sorry. I don't remember using this email >>>>> address. It's not valid. >>>> >>>> ok. >>>> >>>>> I fixed the problem at some point, but I don't remember how, probably >>>>> with some SQL voodoo. >>>> >>>> should be fixable by reversing the database update, so that it >>>> can be applied cleanly. >>>> >>>>> One thing I'm sure : I had neither touched the database nor done >>>>> "upstream migration" before apt upgrade that caused this. >>>> >>>> that's weird, because for some reason you already had the updated >>>> database schema when apt tried to update it. >>>> >>>>> I only found I had reported this bug because I was looking for the >>>>> reason of a similar upgrade failure, with a diferent column, >>>>> resetpass_token this time. >>>>> This bug is definitely unreproducible now, but I'll open a new one for >>>>> resetpass_token. >>>> >>>> That seems to be the same bug. I can't reproduce it, though. >>>> >>>>> BTW, is the database upgrade fragile ? >>>> >>>> not that I'm aware of. I have my own instance of tt-rss and upgrade >>>> it using the same package, which is uploaded to Debian. Actually I >>>> only upload it after testing it on my instance for 1-2 days. >>>> >>>> P.S.: I removed upstream's upgrade plugin from the 1.12 release, >>>> which I uploaded to unstable some hours ago. >>>> >>>> -- Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724292: tt-rss: Database update failed when going from 1.9 to 1.10
Ah I was hit by a breaking change in nginx (5.5.12+dfsg-1), permission changes. It's not related to tt-rss. I'll tell you if tt-rss is still broken so you can close. 2014-05-07 11:25 GMT+02:00 LEDUQUE Mickaël : > Would you know where I can find the logs ? I don't find anything > except this "502". > > 2014-05-07 10:46 GMT+02:00 LEDUQUE Mickaël : >> First attempt to solve it on my side, I tried to answer "abandon" then >> downgrade to 1.11. >> Now I get HTTP 502 (bad gateway, it's served by nginx) on every request. >> >> 2014-05-07 1:39 GMT+02:00 Sebastian Reichel : >>> On Tue, May 06, 2014 at 11:37:40PM +0200, LEDUQUE Mickaël wrote: >>>> Hi, >>>> I'm the same person that reported this bug. >>>> I never had your last answer, sorry. I don't remember using this email >>>> address. It's not valid. >>> >>> ok. >>> >>>> I fixed the problem at some point, but I don't remember how, probably >>>> with some SQL voodoo. >>> >>> should be fixable by reversing the database update, so that it >>> can be applied cleanly. >>> >>>> One thing I'm sure : I had neither touched the database nor done >>>> "upstream migration" before apt upgrade that caused this. >>> >>> that's weird, because for some reason you already had the updated >>> database schema when apt tried to update it. >>> >>>> I only found I had reported this bug because I was looking for the >>>> reason of a similar upgrade failure, with a diferent column, >>>> resetpass_token this time. >>>> This bug is definitely unreproducible now, but I'll open a new one for >>>> resetpass_token. >>> >>> That seems to be the same bug. I can't reproduce it, though. >>> >>>> BTW, is the database upgrade fragile ? >>> >>> not that I'm aware of. I have my own instance of tt-rss and upgrade >>> it using the same package, which is uploaded to Debian. Actually I >>> only upload it after testing it on my instance for 1-2 days. >>> >>> P.S.: I removed upstream's upgrade plugin from the 1.12 release, >>> which I uploaded to unstable some hours ago. >>> >>> -- Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724292: tt-rss: Database update failed when going from 1.9 to 1.10
Would you know where I can find the logs ? I don't find anything except this "502". 2014-05-07 10:46 GMT+02:00 LEDUQUE Mickaël : > First attempt to solve it on my side, I tried to answer "abandon" then > downgrade to 1.11. > Now I get HTTP 502 (bad gateway, it's served by nginx) on every request. > > 2014-05-07 1:39 GMT+02:00 Sebastian Reichel : >> On Tue, May 06, 2014 at 11:37:40PM +0200, LEDUQUE Mickaël wrote: >>> Hi, >>> I'm the same person that reported this bug. >>> I never had your last answer, sorry. I don't remember using this email >>> address. It's not valid. >> >> ok. >> >>> I fixed the problem at some point, but I don't remember how, probably >>> with some SQL voodoo. >> >> should be fixable by reversing the database update, so that it >> can be applied cleanly. >> >>> One thing I'm sure : I had neither touched the database nor done >>> "upstream migration" before apt upgrade that caused this. >> >> that's weird, because for some reason you already had the updated >> database schema when apt tried to update it. >> >>> I only found I had reported this bug because I was looking for the >>> reason of a similar upgrade failure, with a diferent column, >>> resetpass_token this time. >>> This bug is definitely unreproducible now, but I'll open a new one for >>> resetpass_token. >> >> That seems to be the same bug. I can't reproduce it, though. >> >>> BTW, is the database upgrade fragile ? >> >> not that I'm aware of. I have my own instance of tt-rss and upgrade >> it using the same package, which is uploaded to Debian. Actually I >> only upload it after testing it on my instance for 1-2 days. >> >> P.S.: I removed upstream's upgrade plugin from the 1.12 release, >> which I uploaded to unstable some hours ago. >> >> -- Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724292: tt-rss: Database update failed when going from 1.9 to 1.10
First attempt to solve it on my side, I tried to answer "abandon" then downgrade to 1.11. Now I get HTTP 502 (bad gateway, it's served by nginx) on every request. 2014-05-07 1:39 GMT+02:00 Sebastian Reichel : > On Tue, May 06, 2014 at 11:37:40PM +0200, LEDUQUE Mickaël wrote: >> Hi, >> I'm the same person that reported this bug. >> I never had your last answer, sorry. I don't remember using this email >> address. It's not valid. > > ok. > >> I fixed the problem at some point, but I don't remember how, probably >> with some SQL voodoo. > > should be fixable by reversing the database update, so that it > can be applied cleanly. > >> One thing I'm sure : I had neither touched the database nor done >> "upstream migration" before apt upgrade that caused this. > > that's weird, because for some reason you already had the updated > database schema when apt tried to update it. > >> I only found I had reported this bug because I was looking for the >> reason of a similar upgrade failure, with a diferent column, >> resetpass_token this time. >> This bug is definitely unreproducible now, but I'll open a new one for >> resetpass_token. > > That seems to be the same bug. I can't reproduce it, though. > >> BTW, is the database upgrade fragile ? > > not that I'm aware of. I have my own instance of tt-rss and upgrade > it using the same package, which is uploaded to Debian. Actually I > only upload it after testing it on my instance for 1-2 days. > > P.S.: I removed upstream's upgrade plugin from the 1.12 release, > which I uploaded to unstable some hours ago. > > -- Sebastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724292: tt-rss: Database update failed when going from 1.9 to 1.10
Hi, I'm the same person that reported this bug. I never had your last answer, sorry. I don't remember using this email address. It's not valid. I fixed the problem at some point, but I don't remember how, probably with some SQL voodoo. One thing I'm sure : I had neither touched the database nor done "upstream migration" before apt upgrade that caused this. I only found I had reported this bug because I was looking for the reason of a similar upgrade failure, with a diferent column, resetpass_token this time. This bug is definitely unreproducible now, but I'll open a new one for resetpass_token. BTW, is the database upgrade fragile ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724292: Heavy handed fix
Well actually, it didn't really fix anything. The db update script passed, but now, the app is broken. I can see the feeds list, it even shows me I had some unread before the update. But i can't read them, they are only shown in the tree view. 2013/9/24 LEDUQUE Mickaël : > I needed to fix it, so I did > >> alter table ttrss_entries drop column lang > > then I did > > dpkg-reconfigure tt-rss > > and that did the trick. But that's just a workaround. > > By the way, I never altered the mysql schema of tt-rss on this machine > (or on any other machine in fact). > And I'm sure that not relevant, but one never knows : tt-rss doesn't > run on apache or lighthttpd but on nginx. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724292: Heavy handed fix
I needed to fix it, so I did > alter table ttrss_entries drop column lang then I did dpkg-reconfigure tt-rss and that did the trick. But that's just a workaround. By the way, I never altered the mysql schema of tt-rss on this machine (or on any other machine in fact). And I'm sure that not relevant, but one never knows : tt-rss doesn't run on apache or lighthttpd but on nginx. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600288: Still seen in 6b18-1.8.2-2
2010/10/20 Luca Tettamanti : > 2010/10/20 LEDUQUE Mickaël : >> Hello, >> >> I can still see this bug even after upgrading to 6b18-1.8.2-2. > > Hum, yes. > If you upgrade from 6b18-1.8.2-1 javazi data has already been removed, > so it doesn't come back. > Even if you downgrade /usr/lib/jvm/java-6-openjdk/jre/lib/zi remains a > symlink (and the older version shipped with a copy of javazi stuff), > and this confuses the upgrade. > When installing after a purge from either versions everything is fine. > > I also found out that "aptitude reinstall tzdata-java" fixes the issue. > > Luca > Thank you very much, reinstalling tzdata-java fixed the problem. Mickaël -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#600288: Still seen in 6b18-1.8.2-2
Hello, I can still see this bug even after upgrading to 6b18-1.8.2-2. All I have to do is Help>About Eclipse, then click on Installation Details and choose Configuration tab. I'll try to upgrade to the experimental version of openjdk to see if it's fixed there. Mickaël Leduque -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574888: installer: Squeeze alpha1 can't find Broadcom Netlink Gigabit Ethernet card
So, when will there be a debian installer with a newer kernel ? Anyway, even 2.6.32-11 seems a bit outdated... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513382: Filesystem backend
In fact, in my opinion, the point is to not have the data in ANY big, full featured, and space hungry database software. I don't understand why something as simple as an address can't just be stored in whatever file format you could name. Even csv would work! What does a relational database do better when the only kind of search I do is based on the contact name?
Bug#513382: Filesystem backend
So if I set ExternalPayload to true and SizeThreshold to zero, it won't start the mysql server at all? One valuable gain would be to get rid of the mysql dependency, but it won't because the dependency wasn't removed from the akonadi-server package
Bug#513382: Filesystem backend
In the same page that was mentioned earlier http://techbase.kde.org/Projects/PIM/Akonadi#Akonadi_TODO , there is an item "Scheduled for KDE 4.3 / Akonadi 1.2" that is titled "Filesystem backend" and is described as "Store content data in files instead of the database, transfer filehandles instead of data to the client". This item is noted as "DONE". I suppose that now that akonadi is at v1.2 in sid, it is possible to use this? 'and even have it used by default?) Of course, it's possible I misunderstood that.
