Possible SRUs needed for Japanese "Reiwa" era support
Hi! So, I went looking at packages in general that needed SRUs to support the Reiwa era in Japanese. Of those, I've identified glibc, icu, unicode-data, etc... But also some desktop packages (fonts, character maps, etc). I'm listing here the packages that once were in main in supported releases, and as such might still need a fix SRUd. I'm leaving that for the Desktop team to decide when and whether to do the SRUs. Fonts: https://bugs.launchpad.net/ubuntu/+source/fonts-noto-cjk/+bug/1834406 https://bugs.launchpad.net/ubuntu/+source/fonts-takao/+bug/1838345 Character maps: https://bugs.launchpad.net/ubuntu/+source/gucharmap/+bug/1838321 Is gnome-character affected in some releases? Is rebuilding it against a new unicode-data suffice? Input methods: https://bugs.launchpad.net/ubuntu/+source/anthy/+bug/1838346 It also seems like some of the most visible victims have already been addressed: libreoffice and mozc have already been SRUed all the way to Xenial. Note, I'm not a native Japanese speaker, so am I forgetting something? If so, please let me know. -- Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
** Description changed: - * Impact + [Impact] + When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not - When using a VPN the DNS requests might still be sent to a DNS server - outside the VPN when they should not + [Test case] + 1) Set up a VPN with split tunneling: + a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) + b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". + c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". - * Test case + 2) Connect to the VPN. - Configure the system to send all the traffic to a VPN, do a name - resolution, the request should not go to the public DNS server (to be - checked by capturing the traffic by example with wireshark) + 3) Run 'systemd-resolve --status'; note the DNS servers configured: + a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). + b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). + + 4) In a separate terminal, run 'sudo tcpdump -ni + port 53'; let it run. + + 5) In a separate terminal, run 'sudo tcpdump -ni + port 53'; let it run. + + 6) In yet another terminal, issue name resolution requests using dig: + a) For a name known to be reachable via the public network: + 'dig www.yahoo.com' + b) For a name known to be reachable only via the VPN: + 'dig ' + + 7) Check the output of each terminal running tcpdump. When requesting + the public name, traffic can go through either. When requesting the + "private" name (behind the VPN), traffic should only be going through + the interface for the VPN. Additionally, ensure the IP receiving the + requests for the VPN name is indeed the IP address noted above for the + VPN's DNS server. + + If you see no traffic showing in tcpdump output when requesting a name, + it may be because it is cached by systemd-resolved. Use a different name + you have not tried before. - * Regression potential - - The code change the handling of DNS servers when using a VPN, we should - check that name resolution still work whne using a VPN in different - configurations + [Regression potential] + The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) -- You received this bug notification because you are a member of Network- manager, which is subscribed to NetworkManager. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Bug 1621216] Re: [MIR] geoclue-2.0
Unsubscribing ~ubuntu-mir: the MIR for geoclue-2.0 and iio-sensor-prxoy are done, geoclue needs looking at (it's assigned, as per Steve's comment). The MIR team does not need any additional visibility on this since geoclue has already been demoted to universe. -- You received this bug notification because you are a member of Ubuntu Desktop, which is a bug assignee. https://bugs.launchpad.net/bugs/1621216 Title: [MIR] geoclue-2.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/geoclue/+bug/1621216/+subscriptions -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Bug 1075774] Re: [MIR] gstreamer-vaapi
Desktop team, do you care about this package being in main? ** Changed in: gstreamer-vaapi (Ubuntu) Assignee: Matthias Klose (doko) => Ubuntu Desktop (ubuntu-desktop) ** Changed in: gstreamer-vaapi (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Desktop, which is a bug assignee. https://bugs.launchpad.net/bugs/1075774 Title: [MIR] gstreamer-vaapi To manage notifications about this bug go to: https://bugs.launchpad.net/baltix-default-settings/+bug/1075774/+subscriptions -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Ubiquity Proposal - Add "minimal" setup with kernel parameter
On Tue, Jul 25, 2017 at 1:09 PM, Carl Richell wrote: > Hi Mathieu, > > > “Minimal” will contain the least amount necessary to install the OS. We > also prefer off-line installs with minimal which would remove options to > download updates or install 3rd party software during install. This > requires adding language packs to the iso when using minimal. > > > Why could this not be a variation on the OEM install type instead? > > > This would be an additional option to use a minimal set of Ubiquity > screens. "Minimal" and "OEM" could both be chosen. Ubuntu or KDE could use > a separate tool for user configuration if they so chose and reduce > duplication between the installer and user configuration. OEM could use > just OEM or both if they preferred GNOME Initial Setup. > I think I failed to express myself clearly enough: how does this proposal differ from an "OEM" install? It seems to me that it does not. Why is it not feasible to modify OEM mode to use GNOME Initial Setup? Why do we need a separate new option? Ignore the fact that GNOME Initial Setup is GNOME-specific and might not be the best tool for other flavours; what difference exists in the workflow of what you're trying to do vs. what OEM mode currently does? When you add a new option like this, you increase the complexity of a codebase that is already very complex. It doesn't matter if you're ultimately not running some screens, the net effect will be that you will add code to do fewer things. > > This was so hostname could be chosen earlier in the process if the user > config screen is never triggered (where hostname it exist today). Matthew > countered that hostname was supposed to be removed from Ubiquity as part of > the spec and we think he's right. > I must admit that I haven't looked at the design document recently, since I don't really add all that many new features on ubiquity. However, I disagree about removing the hostname option. I defer to Matthew's expertise in UI design, but it seems to me like setting the name of your computer is something that works towards claiming its ownership, and that name *does* show somewhere. It's not irrelevant, and "Matt's computer" or "weeblewobble" (assuming that fits in some naming scheme; the user knows best) means more than "Thinkpad-T450s-f00fbeef" when you need to SSH to it or find some Samba share. > Could you come up with a code branch that does what you want and knows to > install GNOME Initial Setup, or with a pre-made image that mocks up how you > see things, so that we could play with it? > > > Yes, we have an installer sprint coming up at the end of August. There > will be work folks can review. > > Great! Feel free to ask if you have questions; we have the #ubuntu-installer IRC channel just for that. Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Ubiquity Proposal - Add "minimal" setup with kernel parameter
On Tue, Jul 25, 2017 at 8:18 AM, Carl Richell wrote: > Hey Matthew, > > That is not the case: Ubuntu has been using Gnome continuously since 2004, > and when I designed the first iteration of Ubiquity in 2005 we referred to > it explicitly as the “Gnome User Interface”. <https://wiki.ubuntu.com/ > UbuntuExpress/GnomeUserInterface> > > > I probably didn't explain what I meant well. With what's changed since > moving to Unity, and now coming back, particularly GNOME Initial Setup, > Ubiquity does more than is necessary. That's only because we like GNOME > Initial Setup and the out-of-box experience it provides to customers. > How does ubiquity do more than necessary? Which steps do you think should be removed? Is it simply a matter of "it does more than we need if GNOME Initial Setup will run afterwards"? > Our idea is a Ubiquity that only installs the operating system leaving > user configuration to GNOME Initial Setup. > > That's a fair idea, but I think the Ubiquity OEM install option is what would work best for you *right now*; meaning that it already does only install the operating system and leaves the configuration to the end user (just not using GNOME Initial Setup). I know it has issues and is generally not as well tested as the main install path; but this is fixable. If people really care about the OEM install, then they test it, file bugs, and we fix them. Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Ubiquity Proposal - Add "minimal" setup with kernel parameter
On Tue, Jul 11, 2017 at 11:31 AM, Carl Richell wrote: > System76 would like to use GNOME Initial Setup for user configuration. > Currently, there is duplication with Ubiquity. > > We propose changing Ubiquity to add a “minimal” mode, triggered by a > kernel parameter (a flag similar to how OEM install is triggered now). This > enables flavors to use whichever version makes sense for them. System76’s > Pop!_OS and the elementary OS team are interested in using “minimal”. > Minimal might be attractive to Ubuntu w/ GNOME as well. > > “Minimal” will contain the least amount necessary to install the OS. We > also prefer off-line installs with minimal which would remove options to > download updates or install 3rd party software during install. This > requires adding language packs to the iso when using minimal. > > Why could this not be a variation on the OEM install type instead? Installation can proceed as usual, but presumably you don't already know the name of the user you're installing for. In all install cases you'll need to at least take the steps of picking a language and keyboard mapping for the installer (in case you need to also enter other information, such as the OEM ID we ask for to differentiate OEM install batches, crypto password, network authentication to reach a mirror, etc.). The difference is that when you do an OEM install, you do the file copying phase, reboot into an "OEM preparation" environment, so that you can do any further customization of the actual setup (pre-installing some software that wasn't done automatically, checking to make sure everything is as it should, etc). Then you can tell the system that everything is ready, and reboot into the "real" system customization phase that is done by the end user: user name, hostname, timezone, and all of that jazz. Doing so via oem-config or GNOME Initial Setup could just as well be a decision left to the OEM provider. > Minimal screens: > > Welcome/Language Select - change: add KB Layout [1] > > Installation Type - change: move hostname here [2] > > If full disk encryption is chosen, Choose Security Key screen. > > --Timezone: we’d like to remove timezone but Ubiquity is crashing when we > do so. More investigation is necessary. > > [1] KB layout currently comes after “Installation Type”. Users can’t set > their layout before typing a full-disk encryption password. Moving KB > layout forward would fix this. However, Ubuntu uses the first Welcome > Screen to display both language and “Try Ubuntu” or “Install Ubuntu”. A > couple of ideas: > I don't question the need to move the keyboard setup earlier, it just never got to the top of my priority list. That said, there's already an easy workaround, you can choose exactly what keyboard mapping you want before you pick "Try" or "Install" if you booted in BIOS mode (I know, that doesn't work in UEFI yet). We'll get to fixing this eventually (sorry!). > > [2] Hostname is currently on the “Who are you?” screen. It uses the > username and DMI information to populate the hostname. We propose using the > same DMI information, adding 4 hexadecimals to the end (a checksum of the > MAC address “Galag-Pro-A8F3”), and moving the hostname up to the > “Installation Type” screen. This enables “minimal” installs to set the > hostname and business customers can install the OS on multiple machines, > with automatic or custom hostnames, then give the computer to their user > for account setup. > > What would setting the hostname earlier actually bring as a benefit? You can already set automatic/custom hostnames as an enterprise policy via preseeding or via DHCP. For factory systems, it seems to me like there is no benefit in setting any hostname at all (or if there is, please let me know); it's a user decision what they want to call their machine. In an enterprise setting, I would usually not expect people to use an OEM-type install (even your 'minimal' proposal), but rather preseed the installation parameters and only leave to users the few decisions that would make sense -- in an enterprise setting, this often doesn't even include the username. Making users further go through GNOME Initial Setup should already be possible by configuring the final system via a preseed (ie. install the right package, but the right files in so it starts when you log in). My concerns with this are mainly that many of the "advantages" listed in the design document [1] for Initial Setup are already covered by ubiquity as far as I can tell (speed of install, being able to do unattended installs, etc.); with the benefit that it's not tied to any particular desktop environment: ubiquity (oem-config) should work just as well for any desktop environment, without requiring the use of GNOME software (some flavours may not want to use some, for various reasons). We let the end user make customization decisions as late as possible so that we don't block the installation unnecessarily while the user picks a hostname or username. In
Re: Support of firmware updates through fwupd + GNOME Software in Xenial
On Sat, Jan 9, 2016 at 11:31 AM, Amr Ibrahim wrote: > Thanks Bryan, > > The blueprint mentioned using fwupdate directly, not fwupd + GNOME > Software. > > [...] > On 08/01/16 14:00, ubuntu-desktop-requ...@lists.ubuntu.com wrote: > > Hi Amr, > > > > I believe it was discussed at the last summit and if everything lands > > - fwupd[1] and gnome-software - it should theoretically "just work". > > Our focus was on getting the command-line story to work correctly first and foremost. It might be useful to create a new blueprint that depends on the fwupdate one for the tasks needed to get things working with gnome-software from the desktop. One of the steps before one can have fwupd and gnome-software to work for this will be at least completion of the MIR for fwupdate [1]. Looks like gnome-software also is depwait on a new libpackagekit-glib2-dev at least, and would also likely require a MIR. All in all, I'm pretty happy with the current state of integration of fwupdate (at least on the command-line), and it won't be much use to people until there are lots more firmware bits available on the web service fwupd connects to (or until more hardware actually support EFI Capsule). That said, we shouldn't wait for adoption to get this in a better state. If you have time to spend on getting all the bits and pieces ready and available in the distro, please feel free to get things done (and ask for help when needed). I'll be more than happy to sponsor package uploads. [1] https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1508926 Kindly, Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/DC95CA5A 36E2 CF22 B077 FEFE 725C 80D3 C7DA A946 DC95 CA5A -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: XMPP Support in Messaging-App
On Tue, Feb 18, 2014 at 7:45 AM, Kai Mast wrote: [...] > To come to the point: I would really like to implement this! But I > cannot do it by myself. This needs a lot of design work in the > messaging-app and I also need people to give me some help on where to > start. And even then, this is a LOT of work. So, I would hope that some > people will read this and maybe think that they could join me in this task. > Additionally, I would like to see support from the Ubuntu Community that > this feature is actually wanted. Maybe somebody at Canonical is already > working on this? > I for one would absolutely love to see instant messaging as well. That said, I can't currently spend any of my free time working on this (though that could change in May). I'm not aware whether anyone is working on it at the moment. Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: evolution-ews in GNOME3 staging PPA
Sure, I'll look into this. Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 On Mon, Apr 29, 2013 at 12:56 AM, Steve Riley wrote: > The staging PPA has the 3.8 versions of the packages evolution and > evolution-data-server. Are there plans to package evolution-ews as well? > This would be useful for those of us who need to connect to Exchange > servers at work, for instance. > > ...Steve > > > -- > ubuntu-desktop mailing list > ubuntu-desktop@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop > -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop13.04-Topic] Networking health check
This would basically be a re-run of the traditional Networking health check session we've been holding at UDS for a little while, and is more than just Desktop. Are there new things we should make sure we support? (Wireless P2P? 802.11ac? etc.) What things work well, are there currently pain points related to network connections, how we use dnsmasq and resolvconf, etc. and how can we resolve these issues? Are there low-effort, high-benefit things we can do to improve the experience for users and administrators for connecting computers to the Internet or local networks? (for example, last cycle we discussed providing an easy way to use 6to4) Also, not so much a topic or something that requires much discussion, but there are a few things that will need to be done in 13.04 for NetworkManager, ModemManager and nm-applet: - nm-applet upstream code has made a few important changes to UI; I'll make this available in 13.04, the changes simplify the usage of the connection editor a fair amount. - ModemManager 0.6 has been released, and now development is starting on the next version -- I'd like us to aggressively go to the new version, since it will bring a basis for mobile IPv6, and enables quite a few new devices while fixing other issues, improves SMS, etc. all of which we could greatly benefit from. - the new ModemManager will likely require new packages to be made for Debian (I need to look at the details again). And finally, any other things we know will need updates? libnl, wireless-tools, iw, wpa? Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop13.04-Topic] Connectivity checking
I suggested earlier in the Quantal cycle emabling connectivity checking by default; the suggestion brought up quite a lot of interesting discussion which we should bring back at UDS. There are some clear benefits such as being able to handle captive portals more gracefully, but there general idea of being able to know whether an "online" state means having actual Internet access or not brings some benefits, but introduces issues that we need to be prepared to tackle, such as how to reasonably know whether the Internet is reachable, what external servers to use, and how regular traffic generated from this would affect these servers. What needs to be done for connectivity checking to be working properly and efficiently for everyone? How can we make sure privacy and other concerns are taken into account? How can we use connectivity checking to improve the user experience on Ubuntu? Where does connectivity checking tie in to Ubuntu on different form factors? Where could this fail horribly? How can we best test such a feature? Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop13.04-Topic] Mobile IPv6
HI all, IPv6 is becoming more important everywhere, now what there are no longer "free" IPv4 addresses available. That includes supporting IPv6 on mobile broadband (3G/4G modems). There is also some interest from mobile providers in having their systems and devices work properly on Ubuntu, so we should spend time discussing the implications of such work, how it can tie in to Ubuntu on smartphones, tablets, or even TV, etc. ModemManager currently doesn't quite support IPv6 for mobile broadband so easily (although there has been recent work on it [1]). Workarounds exist, wvdial works properly with some configuration. What can we do to make this totally transparent to users, and make sure their mobile ISPs work properly with dual IPv6 before they actually make the switch to it? [1] http://cgit.freedesktop.org/ModemManager/ModemManager/log/?qt=grep&q=ipv6 Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Desktop13.04-Topic] Proxy support
Hi, We started discussing proxy support in Ubuntu last cycle [1]. Keeping in line and expanding on that discussion (and really, taking back some of the work items from there), we should spend some time working with upstream NetworkManager to properly fold in proxy into NetworkManager connections for the desktop. Per-connection proxy support has been in TODO/roadmap for NetworkManager for a little while now; I think we'd benefit from seeing this to completion. Basically, this would mean: - Adding the necessary sections in NM config files for connections to describe proxy settings. - Moving/reworking proxy code elsewhere in GNOME to a "proxy manager" in NetworkManager. - Adding the necessary UI bits to nm-applet, as an extra tab for connections. - Testing, testing, testing. Proxy settings tend to be highly location-dependant, which is why it makes sense to tie them to connections, which also change depending on where a computer is located. This would make the life of mobile workers easier, since they could use a proxy automatically when logged in to their "work" wifi connections, and disabling it automatically when they go home... We should also more generally discuss the current state of proxy support in Ubuntu and what has improved from last cycle, the next steps. etc. In line with testing and with the documentation I started [2], we may also want to spend time setting up the necessary infrastructure for testing proxy support automatically. [1] https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-full-proxy-support [2] https://wiki.ubuntu.com/Testing/Proxy Regards, Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Bug 1038573] Re: Unreadable messages displayed during Lucid -> Precise upgrade
** Changed in: evolution (Ubuntu Precise) Assignee: Ubuntu Desktop (ubuntu-desktop) => Mathieu Trudel-Lapierre (mathieu-tl) -- You received this bug notification because you are a member of Ubuntu Desktop, which is a bug assignee. https://bugs.launchpad.net/bugs/1038573 Title: Unreadable messages displayed during Lucid -> Precise upgrade To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1038573/+subscriptions -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Enabling Connectivity Checking in NetworkManager
On Tue, Jul 10, 2012 at 3:21 PM, Andrea Corbellini wrote: > On 10/07/12 20:41, Mathieu Trudel-Lapierre wrote: >> >> I'd like to enable connectivity checking in NetworkManager. We'd use >> http://start.ubuntu.com/connectivity-check.html, running the check >> every 5 minutes starting from the connection being established. >> start.ubuntu.com has already been in use for a while to verify >> connectivity from the installer, IIRC. > > > Isn't a check every 5 minutes a frequency a bit too high? I mean, if a > computer is connected to a "captive portal which catches and redirects > requests", then the chances that the connectivity will change during time > are very low. In my opinion, having a high frequency will just cause > unnecessary wakeups and will show boring data in tools used for network > debugging. > > Also, what should happen if the connection to start.ubuntu.com times out > because of a network congestion? Has this case been discussed? (I wasn't at > UDS) Great point. I've been considering the implications of that particular frequency. It's the default in NM, and it seems like a reasonable one, but I agree such amount of regular traffic might be an issue for start.ubuntu.com ;) As for whetehr the connection might change during that delay, it's far more about being able to properly catch the change from "captive" to internet access reliably and without delay than the other way around, so perhaps there's something to be fixed there, and stop the check once it's been successful, or at least delay it further. Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Enabling Connectivity Checking in NetworkManager
Hi, At UDS some of us discussed the connectivity checking feature of NetworkManager, which landed not long before the Precise release. Connectivity checking would be a big benefit in helping with properly recognizing the cases where you're connected to wireless, but actually behind a captive portal which catches and redirects requests -- sometimes not all that gracefully. The most frequent impact of this is a corrupted apt cache when the files don't fail to be downloaded, but instead contain http data from the captive portal. I'd like to enable connectivity checking in NetworkManager. We'd use http://start.ubuntu.com/connectivity-check.html, running the check every 5 minutes starting from the connection being established. start.ubuntu.com has already been in use for a while to verify connectivity from the installer, IIRC. The net impact of this change will be a slight modification in the actual status reported by NM -- NM_STATE_CONNECTED_SITE, rather than NM_STATE_CONNECTED_GLOBAL. Most applications that depend on NetworkManager to check connectivity already handle (the old state NM_STATE_CONNECTED which now maps to GLOBAL), CONNECTED_LOCAL, CONNECTED_SITE and CONNECTED_GLOBAL as meaning that they have internet connectivity, so I don't expect consequences for the vast majority of applications. As for the actual change, it is limited to the /etc/NetworkManager/NetworkManager.conf file; to which the following will be added: [connectivity] uri=http://start.ubuntu.com/connectivity-check.html response=Lorem ipsum See the manual page for NetworkManager.conf(5) for the details of what these settings do. Please let me know if you have questions or think there are good reasons not to enable this feature. If there is no response by the end of the week, I'd like to proceed with a enabling this in Quantal and making sure it gets well tested. Kind regards, Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Ubuntu 12.10 Call for Topics
On Tue, Apr 17, 2012 at 6:48 AM, Jason Warner wrote: > Hi Everyone - > > The release is almost here, and right behind (dramatic pause) ... UDS! > > We haven't gotten that many replies to this, which probably means everyone > is heads down getting the final bits of Precise ready to ship (always a good > thing). > > Even so, we need those topics for 12.10 so when everyone gets a chance, > write them up and send them to the list so 1. we can get UDS organized 2. we > can discuss the topic in the ML and 3. we can start to shape 12.10 and see > where we'll be going with it. Not just for Desktop, but I'm planning to have another "NetworkManager health check" session, see if there are things we can take out of how Precise went. Someone already tried to schedule a session for this, though it's not set in stone what we'll be discussing exactly. Perhaps making sure we support some newish wireless features can belong in there: specifically, I mean WPS, WiFi Direct, LTE, WiMAX. Still networking-related for the desktop, I think we should discuss firewalls and proxy again. Is there more work to be done for a better integration of this? How can we get it to work properly? etc. Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: It's time to jettison CCSM
On Thu, Jan 26, 2012 at 11:28 AM, Jorge O. Castro wrote: > With tools like MyUnity now in universe, and didrocks putting basic > configuration in the control panel I'd like to propose the removal of > compizconfig-settingsmanager. > > I don't mean "stop telling people to use it" or "add a warning", I > mean total removal from the archive until the tool is either better > tested or doesn't break people's configuration. Here are some of the > problems with the tool. I agree with all the reasons you've outlined for why it's broken for use with Unity. I've experienced it first-hand as well as see others break their desktops. However, I don't feel it's fair to all our users to drop compizconfig-settings-manager, an application that is presumably useful in environments other than Unity, just because it does not work well with it. I'd be all in favor of making sure it's clear to users that they can thoroughly break their desktop by using it. I do think having the freedom to break your system if you so choose is pretty key to Ubuntu, and I'm certain there are plenty of other packages in universe that allow you to configure your system in a way that you risk breaking something or that are incompatible with some desktop; and that won't be dropped from the archive. That being said, I use CCSM very rarely and wouldn't miss it. ;) Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Developer Application: Mathieu Trudel-Lapierre
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'd like to apply to join the desktop team. Since the last cycle (and before), I've been maintaining or contributing to a number of packages, including NetworkManager (and the related packages), evolution and related packages, gnome-system-tools, and others. Regards, Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJNyjtBAAoJEMEmM+HuAYyTsVEQAMQjaZym+6msx9NuJVwmVjzw q4paXlRQfF5hi1D1EGD9thR1MWvwzp9TOg4RaciwWQgLd7UljaKmuN1x9uMFsrSH BN1AJ4mL7H06iMDy1cGdMif3mdMY2BRym7rQV89c1IEsyX8hrgjjxPkfV27pUvKI TC4BeyfEyHJ2XiT6akkCoK6Wf6mVBbt7VNh0VcW1Tb20Djfw/tVG9jYnKmkqhqSc glED99ggwBP087Bw1hCZCZp2FZSc0nH4PM1kvsfYXjYMor12a0lj57MOjBms6MfU puRSM0x8JnWiEKWT2PvwtAD9TIW6dPlFVz3lkbncnabVlLRoGZ8o/utDUKDyEiAX KQfTvPjGYZAfqMC2xTv6rMofUP1V6yngb0HDQtwOis7KMCcRquqERmd9vnpuHxvD gDXdFdTi17kjNOLHVtefjNaOLMgh84A+c1Y2kgwVbWh7Fm6TPkVH3Jh1rY4T6Zsk B7SJdcPyYAQi+MphtSMIfzf5lU0waVMSg2QF/jR2qaig6YUO0tvy9boXxnaSWJiG ffiqSLRP8uKEHGlfefNBIohj/noDKKpRl/Ue+p3gmQIaRhQfujCPDeUKvcIcv7kb 6WhYc0OdFMyuXYr1ZXN0tYgtapKSJtUsf8ic3ZViM649RgM5CcaKuwv9cQYFLmHe 0OJh5sLUwS5MK+v0mVTe =ejCJ -END PGP SIGNATURE- -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Simplifying system sleep functions
On Tue, Apr 19, 2011 at 8:09 PM, Jason Warner wrote: [...] > 'sleep', the computer should both suspend and hibernate simultaneously. The > computer remains suspended for a set period of time (e.g. 30min) or until > the battery charge falls below a set level. At the point the suspend state > is discarded, and if the user wakes the computer after this point their > state is restored from hibernate. However if the user wakes the computer Won't this not work at all, given that in S3 nothing runs on the CPU, and roughly just the RAM should be powered to maintain programs' state? I rather like Jeremy's suggestion of hiding Hibernate behind a modifier key. Isn't that what Windows does too? Users migrating would then expect it to be to be possible in Ubuntu too, if the computer supports hibernating. Now, whether hibernate works correctly or not is another question, but I think we could further refine checks to make it more likely that it will work if it's presented as a choice to the user. Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Packaging branches
Hi, Thought I might share insight as a relatively new contributor ;) [...] > My experience since moving to bzr branches: > - Much, much faster updating of packages > - Branching packages is possible (e.g. working in a PPA) > - Patches are a little bit harder to do, as the branch doesn't contain > the files from the source tarball I guess I agree, you need to download the orig tarball at that point, but I feel using bzr bd-do to be quite helpful in dropping you straight to a clean unpacked tarball directory once that orig tarball is downloaded. However, I feel it fails when using branches in the normal mode precisely because of patches applied. I've had to unapply patches a few times before running merge-upstream, and it feels rather like a cumbersome and unnecessary step to me. I fear normal mode also leaves room for mistakes such as doing changes in-tree rather than using patches, even if this is probably an easy point of entry for new contributors (quickly getting patches done, to later step into packaging "proper") > - People are often ignoring the branches and uploading directly (or > forgetting do a bzr push) which means changes are sometimes dropped by > accident > - People often do merge requests to lp:ubuntu/package_name, even when > there is a packaging branch Agree. However, I've also run across two or three packages missing a Vcs-* field in debian/control. I believe this should help at least a little. [...] > Some issues that will remain: > - It is possible to screw up the branches so that bzr merge-package > throws a confusing error (I keep doing it). Perhaps we need some hooks > in bzr to stop this from occurring. If it can be broken, it will be > broken (repeatedly). bzr merge-package sounds like one place where using packaging branches in merge-mode would break too, no, seeing as the debian packages are in normal-mode branches? Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Oneiric-Topic] Desktop-side networking enhancements
Hi all, As you may be aware, the next release will most likely bring in the new version of NetworkManager (0.9 now) with all kinds of fun stuff, like WiMAX and me porting the indicator patch to any changes that may have been made to nm-applet for 0.9, unless it makes it upstream before then ;) However, I think it also means it's the right time to look into further things that you may wish to see in the desktop environment to go with NetworkManager. Here I'm thinking about some of the things that came up before in bugs, brainstorm ideas, and the like: - NM integration with firewall configuration - NM integration with proxy configuration - Changing defaults for connection names/notifications/identification of devices - See http://blog.cyphermox.net/2011/03/idea-27250-auto-eth0-isnt-very-user.html I'd also like to turn on IPv6 in NM by default; with the obvious limitation that it won't block interfaces from coming up if there is no IPv6 available. I've limited myself to the *desktop* aspect of things here, but I'm obviously open to idea that won't just affect the Desktop flavour as well. So, any ideas and wild dreams? Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Oneiric-Topic] Reducing number of patches in our packages
On Thu, Apr 7, 2011 at 7:23 AM, Rodrigo Moya wrote: [...] > So, for next cycle, I would suggest a "small" goal of trying to do patch > upstreaming/cleaning days, maybe once a week or every 2 weeks. Great idea :) > Also, some Ubuntu-specific patches, like the appindicators ones are > duplicated in lots of packages, so it would be good if we could find a > better way to make upstream apps use them, like, for instance, patching > gtk_status_icon_* in GTK itself to use the indicators when available, > instead of having to patch dozens of apps (and keep those patches > up-to-date and working for every major version upgrade). > Due to the complexity of keeping an UX that makes sense between using a standard menu and context menu, against having only one menu to use in indicators (to just name one constraint), I think it would be rather difficult to make patching GTK itself to handle indicators work properly.. and especially in a way that looks good. I certainly believe that indicator patches are upstreamable in many cases, and already know that Dan in open to including my indicator patch in nm-applet; I think we're getting close to that being completed too ;) Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
[Bug 438454] Re: NetworkManager fails to set IP and route information entered
AFAICT, the initial issue expressed in this bug report has long since been fixed -- if you see further issues relating to default routes, or configuring connections, please file new separate bugs using 'ubuntu-bug network-manager' which will also make sure we have all the pertinent information about the version of NetworkManager you're using, logs, and error messages. Since the original issue appears to be fixed, I'll mark this bug Fix Released. Thanks! ** Changed in: network-manager (Ubuntu) Assignee: Ubuntu Desktop (ubuntu-desktop) => (unassigned) ** Changed in: network-manager (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Desktop, which is a bug assignee. https://bugs.launchpad.net/bugs/438454 Title: NetworkManager fails to set IP and route information entered -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
