yes, I was hoping it could be shipped because it is already merged and
could solve an ongoing problem.
On Sun, Mar 3, 2024 at 12:23 PM Michael Biebl wrote:
> Am So., 3. März 2024 um 17:28 Uhr schrieb Prateek :
> >
> > Hi,
> >
> > Please create a release with the recent changes.
> > I am unable t
Am So., 3. März 2024 um 17:28 Uhr schrieb Prateek :
>
> Hi,
>
> Please create a release with the recent changes.
> I am unable to see the lid close option in my DE.
> I need the fix delivered in 17c14cc63f9078089a4115d6120f69d24e169636
> Kindly ship a release so that we can get these recent changes
Richard,
thanks for the update. Yes, Android kernels are weird. There are lot of
drivers inside that are not officially supported by Linux, and they are
also not really documented. For example, the Oneplus 5 gives that
entries from upower cmdline:
/org/freedesktop/UPower/devices/battery_battery
/
On Sat, 8 May 2021 at 10:42, Florian Leeber wrote:
> Following up on my investigations on our Android-based mobile devices I
> came to the conclusion that the best solution for solving my fake
> battery problem would be a blacklist.
Is it being exported as a sysfs "power_supply" class?
> I could
04:31, 9 мая 2021 г., "tu4m...@gmail.com" :-- Отправлено из мобильного приложения Яндекс.ПочтыЗагрузки (folder)Хлебные крошки.mp4 (3179)___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dev
Am 07.03.2021 um 23:09 schrieb Florian Leeber:
> Hi guys,
>
> I am Florian from UBports, the community behind Ubuntu Touch, doing
> alternative mobile OS for Android- and Non-Android hardware :)
>
> We are using a customized version of Ubuntu, running off the rather
> outdated 16.04 LTS (but switch
Hi guys,
I am Florian from UBports, the community behind Ubuntu Touch, doing
alternative mobile OS for Android- and Non-Android hardware :)
We are using a customized version of Ubuntu, running off the rather
outdated 16.04 LTS (but switching now to 20.04 soon). Therefore, also
upower tools are in
Hello,
Il giorno lun, 29/06/2020 alle 22.00 +0200, Giuseppe Sacco ha
scritto:[...]
> > According to Wikipedia, the last Powerbook models were discontinued
> > in
> > 2006. I think enabling PMU support more widely, for the benefit of
> > 14
> > year old hardware, seems likely to be an uphill strugg
Hello Simon,
Il giorno lun, 29/06/2020 alle 19.19 +0100, Simon McVittie ha scritto:
> On Mon, 29 Jun 2020 at 19:23:49 +0200, Giuseppe Sacco wrote:
> > Well, this is another problem I am facing. I installed debian linux and
> > it has been officially supported until a two versions ago, when kernel
On Mon, 29 Jun 2020 at 19:23:49 +0200, Giuseppe Sacco wrote:
> Well, this is another problem I am facing. I installed debian linux and
> it has been officially supported until a two versions ago, when kernel
> 3.16 was current.
To be clear about this: neither of the currently-supported Debian rele
Il giorno lun, 29/06/2020 alle 18.38 +0200, Bastien Nocera ha scritto:
> On Mon, 2020-06-29 at 16:06 +0200, Giuseppe Sacco wrote:
>
>
> > If I understood what you wrote, the pmu_battery driver registers the
> > device as of class "power_supply" calling the function
> > power_supply_register() as
On Mon, 2020-06-29 at 16:06 +0200, Giuseppe Sacco wrote:
>
> If I understood what you wrote, the pmu_battery driver registers the
> device as of class "power_supply" calling the function
> power_supply_register() as you may see at line 155 of
> https://git.kernel.org/pub/scm/linux/kernel/git/sta
Hello Bastien,
Il giorno lun, 29/06/2020 alle 15.01 +0200, Bastien Nocera ha scritto:
> On Mon, 2020-06-29 at 14:58 +0200, Giuseppe Sacco wrote:
> > Il giorno lun, 29/06/2020 alle 13.06 +0200, Bastien Nocera ha
> > scritto:
> > > On Mon, 2020-06-29 at 12:00 +0100, Richard Hughes wrote:
> > > > On
On Mon, 2020-06-29 at 14:58 +0200, Giuseppe Sacco wrote:
> Il giorno lun, 29/06/2020 alle 13.06 +0200, Bastien Nocera ha
> scritto:
> > On Mon, 2020-06-29 at 12:00 +0100, Richard Hughes wrote:
> > > On Mon, 29 Jun 2020 at 02:54, Giuseppe Sacco
> > > wrote:
> > > > Browsing UPower source code I not
Il giorno lun, 29/06/2020 alle 13.06 +0200, Bastien Nocera ha scritto:
> On Mon, 2020-06-29 at 12:00 +0100, Richard Hughes wrote:
> > On Mon, 29 Jun 2020 at 02:54, Giuseppe Sacco
> > wrote:
> > > Browsing UPower source code I noticed that PMU device is not
> > > managed at
> > > all, at least on t
On Mon, 2020-06-29 at 12:00 +0100, Richard Hughes wrote:
> On Mon, 29 Jun 2020 at 02:54, Giuseppe Sacco
> wrote:
> > Browsing UPower source code I noticed that PMU device is not
> > managed at
> > all, at least on the Linux branch.
>
> If it helps, HAL used to have code to read from PMU devices.
On Mon, 29 Jun 2020 at 02:54, Giuseppe Sacco
wrote:
> Browsing UPower source code I noticed that PMU device is not managed at
> all, at least on the Linux branch.
If it helps, HAL used to have code to read from PMU devices. I don't
think it got ported all those years ago to DeviceKit-power, the o
Hi,
I went over udev rules events and it turns out I missed rules added by
usbmuxd to /lib/udev/rules.d/ (instead of the custom rules dir
/etc/udev/rules.d). Disabling those rules also stops the weird behavior.
The offending rules are:
```
# systemd should receive all events relating to device
SU
On 9/6/19 4:50 PM, Simon McVittie wrote:
> On Fri, 06 Sep 2019 at 09:52:56 +0200, Vojtěch Trefný wrote:
>> On 9/6/19 4:56 AM, Pau Amma wrote:
>>> So it
>>> should be possible to use the library with a FreeBSD-specific daemon (that
>>> already exists) providing the same messaging interface.
>>
>>
On Fri, 06 Sep 2019 at 09:52:56 +0200, Vojtěch Trefný wrote:
> On 9/6/19 4:56 AM, Pau Amma wrote:
> > So it
> > should be possible to use the library with a FreeBSD-specific daemon (that
> > already exists) providing the same messaging interface.
>
> There might be some other issues with this, lib
On 9/6/19 4:56 AM, Pau Amma wrote:
> On Fri, September 6, 2019 1:23 am, David Lehman wrote:
>> On Fri, 2019-09-06 at 01:07 +, Pau Amma wrote:
>>> I'm considering using just the library from udisks with a replacement
>>> daemon, for use on FreeBSD systems. However, some of the dependencies
>>>
On Fri, September 6, 2019 6:30 am, Marius Vollmer wrote:
> Pau Amma writes:
>
>> I believe that you're correct, but that (unless I'm missing something)
>> libudisks and the daemon communicate using the Dbus message API. So it
>> should be possible to use the library with a FreeBSD-specific daemon
On Fri, September 6, 2019 1:23 am, David Lehman wrote:
> On Fri, 2019-09-06 at 01:07 +, Pau Amma wrote:
>> I'm considering using just the library from udisks with a replacement
>> daemon, for use on FreeBSD systems. However, some of the dependencies
>> stand in my way, like the blockdev library
On Fri, 2019-09-06 at 01:07 +, Pau Amma wrote:
> Hi:
>
> I'm considering using just the library from udisks with a replacement
> daemon, for use on FreeBSD systems. However, some of the dependencies
> stand in my way, like the blockdev library, which as far as I can
> tell is
> only needed for
On Sun, 2019-03-24 at 18:11 -0700, Justin Smith wrote:
> As seen here:
> https://askubuntu.com/questions/1122662/how-can-i-make-upower-and-the-power-subsystem-recognize-that-the-power-supply-is
>
> That is not my post but, it seems, everyone with this laptop is
> having
> the same issue.
>
> I
bject or body 'help' to
> devkit-devel-requ...@lists.freedesktop.org
>
> You can reach the person managing the list at
> devkit-devel-ow...@lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Content
I think is off topic a mail speaking about a rapper:
https://en.wikipedia.org/wiki/Kevin_Gates
in this list should be reported as spam
Valerio
On 11/17/18 01:15, Yash Pal wrote:
Hi Folks,
I writing the mail on behalf of GlobalTechEvent community. We just
started Telegram Channel where we are
I created a merge request. It told me to "Ask someone with write access to
this repository to merge this request". Would notifying this list be
sufficient?
On Wed, Sep 19, 2018 at 2:16 AM Martin Pitt wrote:
> Hello Tom,
>
> Tom Mercer [2018-09-18 17:00 -0400]:
> > Yes, I updated up-device.c, and
Hello Tom,
Tom Mercer [2018-09-18 17:00 -0400]:
> Yes, I updated up-device.c, and did a commit, but I I couldn't push. I
> don't know how to get it examined for inclusion by anyone in charge. Anyone
> on this list can help?
Please send a Merge Request on the gitlab page:
https://gitlab.freedes
Yes, I updated up-device.c, and did a commit, but I I couldn't push. I
don't know how to get it examined for inclusion by anyone in charge. Anyone
on this list can help?
On Tue, Sep 18, 2018 at 3:39 PM Richard Hughes wrote:
> On Tue, 18 Sep 2018 at 19:25, Tom Mercer wrote:
> > I am having a ver
On Tue, 18 Sep 2018 at 19:25, Tom Mercer wrote:
> I am having a very difficult time finding a person who can push changes to
> UPower. Who do I talk to, and through what medium?
Most of us here. Do you have something specific to talk about? :)
Richard
___
2018-07-06 13:23 GMT+02:00 Lennart Poettering :
> Yes, Mantas is right, PrivateNetwork= disconnects the whole of
> AF_NETLINK from the rest of the system, which means services that
> require libudev device events can't use it.
Thank you Lennart and Mantas.
I was indeed not aware that PrivateNetwor
On Mon, 2018-07-02 at 12:19 +0200, Michael Biebl wrote:
> Related to that: Where should bug reports be filed for upower
> nowadays:
> https://bugs.freedesktop.org/describecomponents.cgi?product=upower
> or https://gitlab.freedesktop.org/upower/upower/issues ?
The latter is better, as that makes it
Related to that: Where should bug reports be filed for upower nowadays:
https://bugs.freedesktop.org/describecomponents.cgi?product=upower
or https://gitlab.freedesktop.org/upower/upower/issues ?
2018-06-21 11:04 GMT+02:00 Bastien Nocera :
> On Thu, 2018-06-21 at 00:40 +0200, Michael Biebl wrote:
On Thu, 2018-06-21 at 00:40 +0200, Michael Biebl wrote:
> Hi
>
> 2018-06-20 15:33 GMT+02:00 Bastien Nocera :
> > On Wed, 2018-06-20 at 15:19 +0200, Michael Biebl wrote:
> > > Hi Richard
> > >
> > > 2018-06-19 15:45 GMT+02:00 Richard Hughes :
> > > > Version 0.99.8
> > > > ~~
> > > > R
Hi
2018-06-20 15:33 GMT+02:00 Bastien Nocera :
> On Wed, 2018-06-20 at 15:19 +0200, Michael Biebl wrote:
>> Hi Richard
>>
>> 2018-06-19 15:45 GMT+02:00 Richard Hughes :
>> > Version 0.99.8
>> > ~~
>> > Released: 2018-06-18
>>
>> There is no tarball at https://upower.freedesktop.org/rel
On Wed, 2018-06-20 at 15:19 +0200, Michael Biebl wrote:
> Hi Richard
>
> 2018-06-19 15:45 GMT+02:00 Richard Hughes :
> > Version 0.99.8
> > ~~
> > Released: 2018-06-18
>
> There is no tarball at https://upower.freedesktop.org/releases/
> Is that an oversight or intentional?
It's inte
Hi Richard
2018-06-19 15:45 GMT+02:00 Richard Hughes :
> Version 0.99.8
> ~~
> Released: 2018-06-18
There is no tarball at https://upower.freedesktop.org/releases/
Is that an oversight or intentional?
Regards,
Michael
___
devkit-devel maili
On Tue, 2018-06-19 at 09:38 +0200, Charles-Antoine Couret wrote:
> Some firmware like on Lenovo E560 never sends "fully charged" status.
> The idea is to consider the situation: a battery without energy
> consumption,
> in discharging mode but with AC power plugged is fully charged.
We use GitLab
On Fri, 2018-04-06 at 11:46 -0700, Dmitry Torokhov wrote:
> Newer kernels emit bind/unbind uevents that are not of interest to
> powerd. To avoid littering logs with scary messages, let's lower
> their
> severity to "debug".
The devkit mailing-list isn't an open mailing-list, and we (still) use
bu
On Fri, 2018-02-23 at 14:02 -0800, Andy Holmes wrote:
> Hi,
>
> I had a short conversation with hughsie about inserting an emulated
> device into the list of devices enumerated by UPower, esp DBus. He
> indicated there's little or no documentation on this, but might be
> possible by manipulating a
Hi,
segfault:
> We are currently working on the patches for the unlock dialog in Disks.
> This will probably be finished soon. The resulting UI is much more
> complex than in the LUKS case, but this simply reflects the more complex
> needs of VeraCrypt users.
the Disks patches are ready now, they
Hi,
segfault:
> Hi,
>
> we at Tails (tails.boum.org) currently work on integrating support for
> unlocking VeraCrypt (and probably also TrueCrypt) volumes in Tails via
> udisks2 and GNOME Disks (and maybe also GNOME Files and the GVfs
> monitor). We internally track the status of this work in [1]
.. ink ..:
> On Tue, Nov 14, 2017 at 10:02 PM, segfault wrote:
>
>
>> We do not plan to support creating new TC/VC containers, and I didn't
>> even know that zulucrypt can do this (thanks for the hint!). I find the
>> idea tempting, maybe I will work on that at some point.
>>
>
> zuluCrypt[0] u
On Tue, 2017-11-14 at 20:05 +0100, segfault wrote:
> Vratislav Podzimek:
> > On Mon, 2017-11-13 at 17:36 +0100, segfault wrote:
> > [...]
> > > I forgot to add: Assuming that you would like to have this in upstream,
> > > some heads up for when it would be ideal for us if an upstream
> > > maintain
Vratislav Podzimek:
> On Tue, 2017-11-14 at 17:36 +0900, Kai Lüke wrote:
> [...]
>> * GNOME Disks and GIO/GVFs need to make use of the keyfiles parameter in
>> UDisks (currently lacking for LUKS as well) and a way to select a
>> keyfile from GNOME Shell is needed. One could also decide to explicitl
Vratislav Podzimek:
> On Mon, 2017-11-13 at 17:36 +0100, segfault wrote:
> [...]
>> I forgot to add: Assuming that you would like to have this in upstream,
>> some heads up for when it would be ideal for us if an upstream
>> maintainer was available for reviewing:
>> - We will evaluate the results
Hi,
thanks for the quick reply! I re-add the tails-dev mailinglist to Cc.
Kai Lüke:
> Seems I misunderstood while reading, so you already have code.
Correct. Sorry if I didn't make that clear enough. I will still answer
your previous email below. In case you already want to have a loo
On Tue, 2017-11-14 at 17:36 +0900, Kai Lüke wrote:
> Hello,
>
> of course there is more than one way to do it, but this is how I quickly
> thought about this:
>
> * use the cryptsetup support for locking/unlocking in libblockdev and
> make it work from the UDisks2.Encrypted interface
> * add the
On Mon, 2017-11-13 at 17:36 +0100, segfault wrote:
> segfault:
> > Hi,
> >
> > we at Tails (tails.boum.org) currently work on integrating support for
> > unlocking VeraCrypt (and probably also TrueCrypt) volumes in Tails via
> > udisks2 and GNOME Disks (and maybe also GNOME Files and the GVfs
> >
Seems I misunderstood while reading, so you already have code.
If your way of identifying encrypted partitions works good enough (which
is funny because the partition is not really hidden then) you can ignore
my sentences on presenting those device contents.
From the GNOME Disks point of view it wo
Hello,
of course there is more than one way to do it, but this is how I quickly
thought about this:
* use the cryptsetup support for locking/unlocking in libblockdev and
make it work from the UDisks2.Encrypted interface
* add the UDisks2.Encrypted interface in UDisks if the block device
content c
Hey,
thanks for the quick response!
Bastien Nocera:
> [...]
> What UI differences would be needed to handle those different types of
> encryption? I'm guessing none for handling encrypted disks, because the
> UI should be pretty much the same as for the existing LVM based
> encryption support.
D
Hey,
On Mon, 2017-11-13 at 17:19 +0100, segfault wrote:
> Hi,
>
> we at Tails (tails.boum.org) currently work on integrating support
> for
> unlocking VeraCrypt (and probably also TrueCrypt) volumes in Tails
> via
> udisks2 and GNOME Disks (and maybe also GNOME Files and the GVfs
> monitor). We i
segfault:
> Hi,
>
> we at Tails (tails.boum.org) currently work on integrating support for
> unlocking VeraCrypt (and probably also TrueCrypt) volumes in Tails via
> udisks2 and GNOME Disks (and maybe also GNOME Files and the GVfs
> monitor). We internally track the status of this work in [1] and
Hi guys,
I have filed an issue about this on the github page,..
https://github.com/storaged-project/udisks/issues/409
thanks
On 22/09/17 04:02 AM, Vratislav Podzimek wrote:
On Fri, 2017-09-22 at 07:40 +0200, Martin Pitt wrote:
Hello westlake,
westlake [2017-09-21 14:29 -0400]:
Here as
On Fri, 2017-09-22 at 07:40 +0200, Martin Pitt wrote:
> Hello westlake,
>
> westlake [2017-09-21 14:29 -0400]:
> > Here as a user I'd like to emphasize the intent of udisks,
> >
> > for a long time I have been able to prevent the Linux desktop from
> > auto-mounting usb drives by using udisks --
Hello westlake,
westlake [2017-09-21 14:29 -0400]:
> Here as a user I'd like to emphasize the intent of udisks,
>
> for a long time I have been able to prevent the Linux desktop from
> auto-mounting usb drives by using udisks --inhibit-all-polling.
>
> Is there something udisks2 uses that imple
Hello,
the automount is performed by GVFs which tests for the HintAuto property
in UDisks which is coming from udev.
Therefore you would need to set the udev variable UDISKS_AUTO. I've not
done it myself, but there are examples in the net depending on what
drives your rule should cover.
The string
On Sat, 2017-05-27 at 07:24 -0600, Kevin Locke wrote:
> Hi All,
>
> I'm interested in UDisks support for removing drives connected via a
> dock device, such as the UltraBay in my ThinkPad T430. My
> understanding is that this is not currently supported (e.g. a docked
> hard drive is currently "re
On Wed, 2017-02-15 at 15:38 +0100, Martin Pitt wrote:
> Hello all,
>
> Martin Pitt [2016-11-25 15:32 +0100]:
> >
> > * The current code base of storaged should become "the" official
> > project, and the old udisks 2.1.x should be mothballed after a
> > final merge of the recent fixes into
On Wed, 2017-02-15 at 15:38 +0100, Martin Pitt wrote:
> Hello all,
>
>
> We discussed that in person two weeks ago. We decided that we'll
> rename
> everything back to udisks, so that big PR now landed:
>
> https://github.com/storaged-project/udisks/pull/191
>
> I also closed down the old ud
Hello all,
Martin Pitt [2016-11-25 15:32 +0100]:
> * The current code base of storaged should become "the" official
>project, and the old udisks 2.1.x should be mothballed after a
>final merge of the recent fixes into storaged.
>
> * Personally I would prefer to leave development on Git
Hey,
I'm not sure whether I'm the right person to answer, but here is my few
attempt:
It really depends on how you want to mount. Say you are using udiskie
[1], you can put a rule in the config file, to specify your device as
readonly, like this:
~/.config/udiskie/config.yml:
mount_options:
On Mon, 05 Dec 2016 at 11:39:10 +0200, Marius Vollmer wrote:
> I feel that the only sane thing is to have UTF-8 filenames, and we
> should optimize for that. If we have to deal with multiple encodings,
> the API should ideally protect the client from that by converting to and
> from UTF-8 on D-Bus
On Fri, 02 Dec 2016 at 15:23:19 +0100, Vratislav Podzimek wrote:
> (e.g. byte arrays instead of strings, everything synchronous,...)
There is probably a reason for these design decisions. Think carefully
before breaking them.
Byte arrays on D-Bus, in places where you expect a string, usually mean
On Fri, 2016-12-02 at 15:23 +0100, Vratislav Podzimek wrote:
> Hello again, everyone!
>
> Let me use this opportunity of a general quiet in this thread to try to push
> it further a bit. I believe we have all agreed on the direction we
> would
> like to go with the udisks2 and storaged projects.
Hello again, everyone!
Let me use this opportunity of a general quiet in this thread to try to push it
further a bit. I believe we have all agreed on the direction we would
like to go with the udisks2 and storaged projects. That being the reunification
of the projects using the current storaged
On Mon, 2016-11-28 at 22:22 +0100, Martin Pitt wrote:
> Tomáš Smetana [2016-11-28 14:09 +0100]:
> > One thing we miss at the moment is some good communication channel. Github
> > does not have mailing lists and since storaged is not a Freedesktop project
> > we didn't feel like discussing our stuff
On Mon, 2016-11-28 at 22:17 +0100, Martin Pitt wrote:
> Hello Vratislav,
>
> Vratislav Podzimek [2016-11-28 16:04 +0100]:
> > > * storaged PRs do run some tests, but unfortunately the result links
> > > don't work at all so I don't know what they actually test. I would
> > > hope that at le
Hello Tomáš,
Tomáš Smetana [2016-11-29 18:33 +0100]:
> And.. by chance, does some of the udisks developers plan to attend devconf.cz
> in
> January?
As I said, "all udisks developers" == pitti/10 ☺
But as it happens I actually do plan to attend devconf.cz this year,
it'll be my first one. (I'm
On Mon, 28 Nov 2016 22:22:39 +0100
Martin Pitt wrote:
> Tomáš Smetana [2016-11-28 14:09 +0100]:
> > One thing we miss at the moment is some good communication channel. Github
> > does not have mailing lists and since storaged is not a Freedesktop
> > project we didn't feel like discussing our stu
Hello Vratislav,
Vratislav Podzimek [2016-11-28 16:04 +0100]:
> > * storaged PRs do run some tests, but unfortunately the result links
> >don't work at all so I don't know what they actually test. I would
> >hope that at least build + src/tests/integration-test? If not,
> >that's some
Tomáš Smetana [2016-11-28 14:09 +0100]:
> One thing we miss at the moment is some good communication channel. Github
> does not have mailing lists and since storaged is not a Freedesktop project
> we didn't feel like discussing our stuff here. Perhaps this ML list would be
> a good place to discuss
Simon McVittie [2016-11-28 14:16 +]:
> If the maintainers of udisks2 are happy with doing so, I would
> advocate using the udisks[2] name
FTR: I'm the closest thing to a maintainer right now (and I'm doing a
really bad job at it), and I'm happy with it :)
Martin
--
Martin Pitt
replacement, I think we should end
> this forking and re-unify the projects again:
Hello everybody,
this is really great news and I cannot even express how much happy this
proposal makes me. It definitely makes sense to join the efforts and
focus on a single codebase instead of porting pat
gt; udisks, we didn't want to use the same package or even project name.
If the maintainers of udisks2 are happy with doing so, I would advocate
using the udisks[2] name, particularly if storaged provides the udisks2
API anyway. When gcc and egcs re-merged, the result was named gcc after the
par
storaged is not a Freedesktop project
we didn't feel like discussing our stuff here. Perhaps this ML list would be
a good place to discuss the project's merge.
> * We can decide later whether we want to mass-close the fd.o bugs at
>some point and ask people to re-submit issue
there is a
high chance that I'll have more time for it from next year on.
But especially since the API and CLI of storaged got renamed back to
"udisks" and it's now a drop-in replacement, I think we should end
this forking and re-unify the projects again:
* The current c
On Wed, Jul 06, 2016 at 05:54:39PM +, Leslie S Satenstein wrote:
> With Fedora 24, sadly, upower 99.4 fails to show the APC UPS that I have
> plugged into usb#6. It is reporting correctly for other Linux versions. For
> example, with Fedora 23, upower 99.4 lists the UPS quite correctly.
On Mon, 2016-10-17 at 04:01 +0200, Alexander Couzens wrote:
> It's useful for setups which don't support hibernate.
I don't think it is, but you can discuss this here:
https://bugs.freedesktop.org/show_bug.cgi?id=73435
Cheers
___
devkit-devel mailing li
On Wed, 2016-03-16 at 00:02 +0100, Bastien Nocera wrote:
> On Tue, 2016-03-15 at 16:59 -0400, Nathaniel McCallum wrote:
> >
> > Sorry for the cross-post! However, I figured it was the best way to
> > reach all the right people.
> >
> > I'm the author of the Tang[1] project. In a nutshell, Tang pr
On Wed, 2016-03-16 at 17:51 -0400, Nathaniel McCallum wrote:
> On Wed, 2016-03-16 at 00:02 +0100, Bastien Nocera wrote:
> >
> > On Tue, 2016-03-15 at 16:59 -0400, Nathaniel McCallum wrote:
> > >
> > >
> > > Sorry for the cross-post! However, I figured it was the best way
> > > to
> > > reach all
On Tue, 2016-03-15 at 16:59 -0400, Nathaniel McCallum wrote:
> Sorry for the cross-post! However, I figured it was the best way to
> reach all the right people.
>
> I'm the author of the Tang[1] project. In a nutshell, Tang provides a
> way to bind an encrypted disk to a network. We currently prov
Hi!
Looks like libupower-glib dropped quite a few symbols, specifically:
up_client_glue_*
up_device_glue_*
up_wakeups_glue_*
On the other hand, a lot of new symbols were added, matching up_exported_*
Those are not part of the public API, so I guess dropping those symbols was ok.
Could we please
Federico Di Pierro wrote:
> So, my question: is there a way to check if the dbus interface is up
> (or to wait until it is)?
There is:
org.freedesktop.DBus.ObjectManager.InterfacesAdded
--
pocek
___
devkit-devel mailing list
devkit-devel@lists.freedes
On 2 December 2015 at 19:41, Daniel Reurich wrote:
> Is there any chance we could reintroduce the support for
> suspend/hibernate/poweroff back in for non-systemd systems into the 1.0
> series. This is important still for non-systemd OS's including Devuan
> and the *BSD's
No, sorry. pm-utils is
Apologies,
I should have been specific this request is with regards to the dropping
of pm-utils support in 0.99 release of upower.
Thanks,
Daniel
On 03/12/15 08:41, Daniel Reurich wrote:
> Hi,
>
> Is there any chance we could reintroduce the support for
> suspend/hibernate/poweroff bac
Hi,
Is there any chance we could reintroduce the support for
suspend/hibernate/poweroff back in for non-systemd systems into the 1.0
series. This is important still for non-systemd OS's including Devuan
and the *BSD's
I'm not much of a developer myself, but possibly could rope somebody to
do the
On Thu, 2015-11-19 at 10:30 +0100, Tomáš Smetana wrote:
> On Wed, 18 Nov 2015 17:40:33 +0100
> Bastien Nocera wrote:
>
> > On Wed, 2015-11-11 at 11:27 +0100, Tomáš Smetana wrote:
> > > Hello.
> > >
> >
> > > If udisks2 upstream would be willing to support the server-type use
> > > cases, we wou
On Wed, 18 Nov 2015 17:40:33 +0100
Bastien Nocera wrote:
> On Wed, 2015-11-11 at 11:27 +0100, Tomáš Smetana wrote:
> > Hello.
> >
>
> > If udisks2 upstream would be willing to support the server-type use
> > cases, we would of course gladly join them. But again: it's already many
> > years old
On Wed, 2015-11-11 at 11:27 +0100, Tomáš Smetana wrote:
> Hello.
>
> If udisks2 upstream would be willing to support the server-type use cases, we
> would of course gladly join them. But again: it's already many years old
> topic. And unless udisks2 upstream changes their mind, there is no other
On 16.11.2015 17:16, .. ink .. wrote:
On Mon, Nov 16, 2015 at 5:47 PM, Guy wrote:
- An example: Good old udisks told us the name of files associated with loop
devices. This information is queried directly from the loop device driver,
by using an ioctl call. The consequence is, that this info
As promised, I let you know about my solution to circumvent the udisks2
problems. A small and ugly program for collecting the most important
information about block devices can be found here:
http://faert.net/jangdeblannen/udevblk.c
This solution is not free of problems neither:
- libudev is
On Fri, 2015-11-13 at 12:47 +, Mueller, Daniel wrote:
> Hi
Can you please put your patches in Bugzilla? That way they don't get
lost.
Cheers
___
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listin
On 10/30/2015 05:02 PM, .. ink .. wrote:
On Fri, Oct 30, 2015 at 12:51 AM, Guy wrote:
This leaves me with a strange feeling... can I rely on udisks2?
Probably not as you are not the target audience,look at "audience"
section in the following link
for more info: http://udisks.freedesktop.org/
On 10/29/2015 10:02 PM, Thomas Gläßle wrote:
Hey,
I should add as disclaimer that I am only a udisks user, so you might
very well know more about this topic than I do and I am not qualified
to give you definite answers, very sorry :(.
We're sitting in the same boat then...
No need to be sorr
Hey,
Guy wrote on 10/28/2015 10:32 PM:
> - Guymager needs to find out the Linux device name for each drive.
> That would be /dev/sda, for example.
>
> - Now comes my problem: How can I find out, which Linux device name
> belongs to which drive? For doing so, I would have to look at the
> block_dev
Hey,
John wrote on 09/18/2015 09:18 PM:
> Hello. I am currently using a helper script which, when users add themselves
> to /etc/sudoers will mount an overlayfs mount and umount it for them. I'd
> like a more elegant way to do this and believe udisks/udisks2 might be that
> solution. I am no
Bastien Nocera wrote on 09/01/2015 03:42 PM:
> You should send the patches either here, or attach them to bugzilla
> using something like "git-bz".
Oh thanks, didn't know about this tool. I'll have a look if that's what
it takes.
> You forked an unofficial mirror of the
> freedesktop.org reposit
1 - 100 of 1301 matches
Mail list logo
